How would you mount a network share that contains a space in the path?
Also, I’ve followed your guide for CIFS shares, but all my shares are mounted with ownership root:root. I’m note sure how to change this. I used to pass the user option to mount via my fstab entry, but it seems to be ignored here.
I consequently avoid non ascii characters - but you may be able to use what @FadeMind commented on the old forum
Avoid non ascii with shares - but that said it could be that systemd-escape is capable of creating the correct naming - you would have to try it though.
$ systemd-escape -p "share name with spaces"
share\x20name\x20with\x20spaces
The user is one part of the credentials to access the share and under Linux permissions are either no access, read or read/write.
When you mount using fstab or systemd the mount is created by root - thus making the content served from the remote share owned by root.
To tell systemd the particular share is writable you use the file_mode and dir_mode options.
I thought the rw option was ignored by mount.cifs? Switched my file_mode and dir_mode options to 0777. Seems to have worked.
I would normally avoid theuse of white space in the path, but I can’t on this occasion as it’s my employer’s share. I’ve tried the following but I still can’t get it to mount:
[Unit]
Description=Project share
After=network.target
[Mount]
What=systemd-escape -p --suffix=path "//wincluster.place.ac.uk/f/share name with spaces"
Where=/data/tux/projdir
Options=_netdev,nofail,rw,credentials=/home/tux/.smbcredentials,sec=ntlmv2,file_mode=0777,dir_mode=0777,iocharset=utf8,vers=3.0
Type=cifs
TimeoutSec=30
[Install]
WantedBy=multi-user.target
When you mount you can specify initial preferred permissions but as smb is a reverse engineered Microsoft protocol - it is hacky at best.
Usually mounting a disk device you can get away with using defaults but that don’t work with shares where the server controls what you may or may not do.
With smb - the options - are only serving the purpose of instructing the system - that if attempts are made to write to the mount point - allow them - but in the end it is the server that denies/allows write access to the share in question.