windows network drive linux mount requires sudo after mounted

Question

I am able to mount a drive to the linux box using sudo.

sudo mount \
    -t cifs \
    -o 'vers=3.0,username=myuser,domain=mydomain' \
    '//windows-ip/share-folder' ~/testmount/

This works great, problem is, when I go into the ~/testmount and do sometihng like mkdir it says:

mkdir: cannot create directory ‘bkup’: Permission denied

It will work if I use sudo We are going to have an automated script in a cronjob write files to these mounts so, we need to be able to write to the mounts without sudo.

So after it’s mounted I’m unable to add files to that folder unless I use sudo and that's the problem.

It seems my problem is very similar to this one, but the solutions for that one didn't work for me:

https://unix.stackexchange.com/questions/231230/mount-successful-directory-accessible-but-cannot-do-operations-cp-mkdir-etc

Someone suggested the problem was that I used sudo to mount it and therefore had to use sudo to change anything in it (even though I don't need to use sudo to read stuff in it).

So, I found answers like these:

https://unix.stackexchange.com/questions/365308/use-mount-o-with-a-non-root-user https://wiki.ubuntu.com/MountWindowsSharesPermanently

I even tried to implement the solutions suggested but was still unable to get those solutions to work either.

My etc/fstab has this line:

//windows-ip/share-folder \
/home/mysuer/testmount \
cifs \ 
uid=myuser,credentials=/home/myuser/.smbcredentials,iocharset=utf8,domain=my-domain 0 0

With the above setup when I try to run mount without sudo I get an error:

$ mount ~/testmount
mount: only root can mount //10.1..../shared on /home/.../testmount

The reason I need to be able to write to these mounted folders without sudo because we will have an automated system saving files and I don't think it should use sudo, and I don’t even know if it could if we wanted it to.

I'm on centos 7. Perhaps you can't put the 'domain' option in the fstab, I don't know. can anyone help me with this?

Answer 1

Mounting and then accessing are two different things.

To allow users to mount, the fourth field in your fstab must contain user, e.g. user,uid=myuser,…. See man 5 fstab. You may not need it though, keep reading.

You give uid=myuser option. From man 8 mount.cifs:

uid=arg
sets the uid that will own all files or directories on the mounted filesystem when the server does not provide ownership information. It may be specified as either a username or a numeric uid. When not specified, the default is uid 0. The mount.cifs helper must be at version 1.10 or higher to support specifying the uid in non-numeric form.

Another fragment:

mount.cifs -V command displays the version of cifs mount helper.

With uid= specified properly, mounting with sudo shouldn't override it; so you may even not need the user option in fstab. Maybe you were almost there when you used uid= but you fixated on not using sudo. There's one more thing though. Yet another fragment:

The core CIFS protocol does not provide unix ownership information or mode for files and directories. Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. Attempting to change these values via chmod/chown will return success but have no effect.

When the client and server negotiate unix extensions, files and directories will be assigned the uid, gid, and mode provided by the server. Because CIFS mounts are generally single-user, and the same credentials are used no matter what user accesses the mount, newly created files and directories will generally be given ownership corresponding to whatever credentials were used to mount the share.

If the uid's and gid's being used do not match on the client and server, the forceuid and forcegid options may be helpful.

If I get it right, a client and a server (when properly set up) can ignore uid= and use ownership stored on the server. In this case this is relevant:

forceuid
instructs the client to ignore any uid provided by the server for files and directories and to always assign the owner to be the value of the uid= option.

It looks like this line in fstab may work better for you:

//windows-ip/share-folder \
/home/mysuer/testmount \
cifs \ 
forceuid,uid=NUMBER,credentials=/home/myuser/.smbcredentials,iocharset=utf8,domain=my-domain 0 0

Then you mount with sudo (or add the user option if you really need it). Without noauto option the OS will try to mount the share automatically at boot. Network may not yet be available at the time, I don't know if your OS will resolve this. With systemd you can use x-systemd.automount, the fourth field would begin with:

x-systemd.automount,x-systemd.idle-timeout=1min,forceuid,uid=NUMBER,…

The alternative is autofs.