How To Mount a Windows Share on Ubuntu 16.0.4 LTS
Recently I just installed Ubuntu 16.0.4 LTS on my Dell laptop and needed to connect to my cifs share off the FreeNAS and ran the normal mount command and it failed. Never been an issue on Fedora 24 and a new install but has been many years since I have been on Ubuntu.
From the above line you see that I am passing the dir_mode and file_mode parameters to make sure that I can read / write the share. This has always worked in the past and up until Fedora 25 and Ubuntu 16.04 was not an issue. Very puzzling when it stopped working.
After a bit of digging I found the fix. First step is to install cifs-utils, to allow Ubuntu to access the CIFS file system. With Fedora this is already part of the installation.
$ sudo apt-get install cifs-utils
So now we have support installed and want to mount a Windows share in read / write access.
In the past I had been mounting it via command line, with the following syntax and was never a issue, it just worked.
$ sudo mount -t cifs //WINSRV/SHARE ~/localmount -o user=userid,pass=mypass,dir_mode=0777,file_mode=0777
The mount command was successful and I could see the files copy but when I tried to paste or create a file I received a permission denied, but sudo in-front of the command no issue. Opening up the man page on mount.cifs answered the question on why. Looking for changes from the default from previous versions found the cache= variable had changed from loose to strict from version 3.7.
Cache refers to Cache Coherency, according to the man page.
The CIFS protocol mandates (in effect) that the client should not cache file data unless it holds an opportunistic lock (aka
oplock) or a lease. Both of these entities allow the client to guarantee certain types of exclusive access to a file so that
it can access its contents without needing to continually interact with the server. The server will call back the client when
it needs to revoke either of them and allow the client a certain amount of time to flush any cached data.
The cifs client uses the kernel’s pagecache to cache file data. Any I/O that’s done through the pagecache is generally page-
aligned. This can be problematic when combined with byte-range locks as Windows’ locking is mandatory and can block reads and
writes from occurring.
cache=none means that the client never utilizes the cache for normal reads and writes. It always accesses the server directly
to satisfy a read or write request.
cache=strict means that the client will attempt to follow the CIFS/SMB2 protocol strictly. That is, the cache is only trusted
when the client holds an oplock. When the client does not hold an oplock, then the client bypasses the cache and accesses the
server directly to satisfy a read or write request. By doing this, the client avoids problems with byte range locks.
Additionally, byte range locks are cached on the client when it holds an oplock and are “pushed” to the server when that
oplock is recalled.
cache=loose allows the client to use looser protocol semantics which can sometimes provide better performance at the expense
of cache coherency. File access always involves the pagecache. When an oplock or lease is not held, then the client will
attempt to flush the cache soon after a write to a file. Note that that flush does not necessarily occur before a write system
call returns.
One other item is the noperm option.
When you connect using CIFS to a server which supports Unix permissions (e.g. Samba), CIFS will by default try to enforce remote Unix ownership UIDs and Unix permissions when you try to access the share. i.e. if a file is owned by UID 502 on the remote server, then the local kernel will try to enforce the same permissions if it were owned by UID 502 on the local machine. Note: This has nothing to do with the remote server’s security settings. This is an extra local ownership enforcement by the filesystem driver. It is a feature to allow use of remote share as a local drive with full Unix permissions enforcement if users match.
But if this is a public share, then chances are, the remote UIDs will not make sense locally. A remote UID might be a completely different user or might not exist at all on the local machine. If remote UIDs and local UIDs do not match, then local users will have trouble using the share. To disable this, use the “noperm” mount option. Remote permissions and UIDs will still be visible, but they will not be enforced locally.
So which option to use? Easy, put it back to what was default before, cache=loose. So our command line is now:
$ sudo mount -t cifs //WINSRV/SHARE ~/localmount -o user=userid,pass=mypass,cache=loose,noperm,dir_mode=0777,file_mode=0777
Back in business and able to access the files again in read / write mode.
I have a ‘clean’ win10 ‘reset’ that blew my system away. it does read external drive.
I did this to install ubuntu, probably 16.04 or higher.
I am not a nerd, but purchased nthis machine – Dell inspiron 17 5767 – without realising that canonical had not certified it. I assumed that I could set up a dual boot win10 and ubuntu.
after reading your pages, I wonder if ‘clean’ is not exactly that. or can I just go ahead and load ubuntu iso via usb?
I could not get the usb iso of ubuntu 16.04 to boot, and the external dvd drive read an old dell devices and drivers cd (ancient) only to all wait and darken.
so all looks well. if actually clean…where to now?
win10 drove crazy for any number of reasons. but mostly because it seems to have been designed to exclude those of us that see ‘slowly’ and poorly in what human eye were were given, by the great DOG in the sky. sidebars, pointers, folders…. cannot be improved.
Linux has the penguin and s/he is welcome.
sudo mount -t cifs //192.168.1.2/NAS /home/ubuntu/NAS -o user=user,pass=pass,cache=loose,noperm,dir_mode=0777,file_mode=0777
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
What have I done wrong?
It is possible it could be wanting the sec= option. Try adding sec=ntlm to you options.