Mount cifs Network Drive: write permissions and chown

Question

I have access to a cifs network drive. When I mount it under my OSX machine, I can read and write from and to it.

When I mount the drive in ubuntu, using:

sudo mount -t cifs -o username=${USER},password=${PASSWORD} //server-address/folder /mount/path/on/ubuntu

I am not able to write to the network drive, but I can read from it. I have checked the permissions and owner of the mount folder, they look like:

4.0K drwxr-xr-x  4 root root    0 Nov 12  2010 Mounted_folder

I cannot change the owner, because I get the error:

chown: changing ownership of `/Volumes/Mounted_folder': Not a directory

When I descend deeper into the network drive, and change the ownership there, I get the error that I have no permission to change the folder´s owner.

What should I do to activate my write permission?

Solution 1

You are mounting the CIFS share as root (because you used sudo), so you cannot write as normal user. If your Linux Distribution and its kernel are recent enough that you could mount the network share as a normal user (but under a folder that the user own), you will have the proper credentials to write file (e.g. mount the shared folder somewhere under your home directory, like for instance $HOME/netshare/. Obviously, you would need to create the folder before mounting it).

An alternative is to specify the user and group ID that the mounted network share should used, this would allow that particular user and potentially group to write to the share. Add the following options to your mount: uid=<user>,gid=<group> and replace <user> and <group> respectively by your own user and default group, which you can find automatically with the id command.

sudo mount -t cifs -o username=${USER},password=${PASSWORD},uid=$(id -u),gid=$(id -g) //server-address/folder /mount/path/on/ubuntu

If the server is sending ownership information, you may need to add the forceuid and forcegid options.

sudo mount -t cifs -o username=${USER},password=${PASSWORD},uid=$(id -u),gid=$(id -g),forceuid,forcegid, //server-address/folder /mount/path/on/ubuntu

Solution 2

I tested the following command successfully:

sudo mount -t cifs -o username=[username],password=[password],uid=1001,gid=1001 //172.16.148.2/dfsgob01 /home/ususario/Documentos/benz-win

Comments

[Jenny D]

Is the file system listed in /etc/fstab? If so, what options does the entry have?

[Daniel]

You can also use the noperm mount option similarly stated in my answer to this question: unix.stackexchange.com/a/375523/16287. This will give all users read and write access to the CIFS mount.

[nvd]

Use "id -u <user>" and "id -g <user> to get the uid and gid respectively.

[João Portela]

it worked for me! But we should add that if the shared folder is in a PC with a login domain you should add the option domain. Something like this: sudo mount -t cifs -o username=${USER},password=${PASSWORD},dom=${DOMAIN}, uid=<user>,gid=<group> //server-address/folder /mount/path/on/ubuntu In fact the domain can go in the "username" option, but remember that you have to use / instead of `, like username=DOMAIN/user.name`.

[Huygens]

Yes, that's correct. :-) One might need to specify the domain or workgroup (for older Windows version) via the "domain=" option or via the username, that's a good point. And sometimes it is even necessary to specify the encryption scheme or the CIFS version to be used. But all this was not part of this question, so I left it aside. :-)

[Waruna Wijesundara]

This is just what I needed. I had an entry in /etc/fstab to auto mount the network drive on startup. I could not write to the mount so I added ,uid=<myUserID> for a line that looks like this: //192.168.1.7/public /colmustang cifs username=<uname>,password=<upassword>,uid=<myUserID> 0 0

[71GA]

One question. Why do we specify user two times? First we have username=... and then uid=...? If I have created a new user like useradd -s/bin/bash -m -g users dijak on host, should I use gid=users?

[Huygens]

@71GA username is the remote login to use for authentication. The uid is the local user ID you want to nap all files/folders. So the username is decoupled from the uid, the username is the remote user login while the uid is your local user id. Note that it could be the same thing if your server is Samba and you use an LDAP or other centralized account on both client and server :-).

[71GA]

Thank you very much for the explaination! It is very helpfull and I must say I respect that people like you are willing to help on the forums. For me samba works best if I create a new user, put a shared folder in it's home directory and then create a symbolic link to this folder in my main user's home directory. If I put shared folder anywhere outside of the new user's home directory I experienced lots of troubles.

[Gilles 'SO- stop being evil']

FYI jstricker's edit suggestion is being discussed on meta.

[conceptdeluxe]

To avoid writing the password alongside the command just omit the password option during the call - a prompt will then ask for it so it can be typed in invisibly.

[Soonts]

Doesn't work for me, even with uid,gid,forceuid and forcegid it’s still read-only.

[Huygens]

@Soonts This might be due to other problems. We could open a chat if you want to try helping. One useful thing could be to check your system log message (the message or syslog file under /var/log/, or using journalctl) and the print of the command mount -t cifs.

[Tak]

@Gilles how I can automatically fetch the uid and gid? so that I don't have to manually set it everytime I mount a server?

[Gilles 'SO- stop being evil']

@Tak Good question. See the edited answer.

[Tak]

@Gilles thank you. And what if I wanted to do this in the /etc/fstab file?

[Tak]

@Gilles I’ve posted a question here unix.stackexchange.com/q/457921/85865 but the answer provided didn’t address the question to automatically fetch the uid and gid

[Ben Johnson]

I'm surprised that nobody has mentioned file_mode and dir_mode, which can be used (in conjunction with the other options discussed) to fine-tune access control in this and similar scenarios.

[Huygens]

@BenJohnson the files were owned by root:root. So you could add your user to the root group and set permissions for the group to be writable or you can set the other as writable. Both solutions are far from ideal and I am not recommending them. Hence I do not mention file and dir mode.

[Manuel Jordan]

@Huygens about If the server is sending ownership information - How know if the server is sending that info or not?.