I have decided to switch to Linux from Windows a month ago, and therefore mounted the Shares via NFS.
I use the following config (removed IPs and names just to be save):

Export as Private with the following rules:
<ipofclient>(async,no_subtree_check,rw,sec=sys,anongid=100,anonuid=99,root_squash)

and in my fstab i have the following mount
<ipofserver>:/mnt/user/<share> /mnt/unraid/<sharename> nfs hard,timeo=50,retrans=5,relatime,rsize=1048576,wsize=1048576 0 0

Whenever I create a file it is owned by the user I am using on my linuxbox (the username exists on unraid as well)

and has the permissions drwxr-xr-x" for Directories and "-rw-r--r--" for files.

Other things I tried so far:
- nfs4 instead of nfs - no difference
- umask=022 - error when trying to mount the share


I read in some spaces that i should use setfacl to enforce permissions but I haven't found a guide to acl yet that gave me the confidence of messing around with permissions for my shares.

I also noticed that when I use docker apps (i.e double commmander) created folders and files get the same permissions but at least the user is set to nobody instead of my username, so it might be a general setting in unraid that is wrong.

I am currently running Unraid 7.2.0

Try umask=000

The permissions need to be drwxrwxrwx and -rw-rw-rw- for things to work right as Unraid is setup.

I believe that the recommended permissions for security purposes by the Linux security Gurus is now 755 and 644. These recommendations have made their way into many Linux distributions recently.

You might actually find it easier to install Samba and set up SMB on your Linux client.

I cannot get SMB automounted, that is why I switched to NFS

when I manually connect to the SMB server I can enter username and password, and everything works as intended.

But whenever I add the Share via FSTAB I get a 177 error that implies I don't have write access.

//<server>/<share> /mnt/unraid/<sharename> cifs defaults,credentials=/home/<user>/.smbcredentials,rw 0 0
and
//<server>/<share> /mnt/unraid/<sharename> cifs defaults,credentials=/home/<user>/.smbcredentials,,uid=99,gid=1000,iocharset=utf8,vers=3.0,nofail,rw 0 0

Both produce the following error when trying to write a file



All Shares that I didn't mount but authenticated manually in dolphin with the same credentials still work....

1 hour ago, Sam_Axe said:

I cannot get SMB automounted, that is why I switched to NFS

Sorry, I am not a Linux Client Samba expert. You will have to either wait for someone else to read this thread or open a new thread and ask for instructions on how to 'auto- mount' SMB shares. Have you inquired on the support site or documentation for the Linux distribution that you are using? (I can't believe that you are the only one who wants to be able to to this...) A new thread might be a better option than waiting for a reply in a thread that basically is about NFS problems.

Edited January 13Jan 13 by Frank1940

I use SMB exclusively between all my Linux servers and Unraid, all using systemd automount. On Unraid, export the share using SMB. On the Linux client, here is my setup:

/etc/fstab

//<unraid host>/<sharename>  /mnt/<mountpoint>  cifs  rw,guest,uid=99,gid=100,_netdev,noatime,noserverino,noperm,cache=none,x-systemd.automount,x-systemd.idle-timeout=600,exec  0  0

What this does:

• rw = read and write access

• guest = connect without a username/password (guest access)

• uid=99 = treat files as owned by local user ID 99

• gid=100 = treat files as owned by local group ID 100

• _netdev = wait for network before mounting

• noatime = don’t update “last accessed” timestamps

• noserverino = don’t use server inode numbers (avoid inode-related issues)

• noperm = don’t enforce local Linux permissions; let the server decide

• cache=none = disable client-side caching (reduce stale reads)

• x-systemd.automount = mount on first access, not at boot

• x-systemd.idle-timeout=600 = unmount after 10 minutes of inactivity

• exec = allow running programs from the mount

• final 0 = don’t include in dump backups

• final 0 = don’t run fsck checks on it

Change the above for your requirements.
I also create a dedicated “Unraid” identity on the Linux box so UID/GID 99/100 are clearly identifiable when you do ls -l:

# make sure group 100 exists (name it whatever you want)
groupadd -g 100 unraid
# create a system user with no home and no shell, pinned to UID 99 / GID 100
useradd -u 99 -g 100 -M -r -s /usr/sbin/nologin unraid

Then run the following:

mkdir -p /mnt/<mountpoint>
systemctl daemon-reload

Sanity checks (make sure the required systemd targets/units are active):

systemctl is-enabled remote-fs.target
systemctl is-active remote-fs.target

(Optional) If you want to confirm systemd actually created the automount unit:

systemctl list-units --type=automount | grep -F "<mountpoint>"

Important note about automount: x-systemd.automount is mount-on-access. It will NOT mount the share until something actually touches the mountpoint. So if you do this and then run df, you’re not going to see anything yet, that’s expected. df will only show it after the mount is triggered.

Now trigger the mount by accessing the directory:

cd /mnt/<mountpoint>
# or:
ls /mnt/<mountpoint>

After that, df should show the mounted share.

Edited January 13Jan 13 by TrevP

19 hours ago, TrevP said:

I use SMB exclusively between all my Linux servers and Unraid, all using systemd automount. On Unraid, export the share using SMB. On the Linux client, here is my setup:

/etc/fstab

//<unraid host>/<sharename>  /mnt/<mountpoint>  cifs  rw,guest,uid=99,gid=100,_netdev,noatime,noserverino,noperm,cache=none,x-systemd.automount,x-systemd.idle-timeout=600,exec  0  0

What this does:

• rw = read and write access

• guest = connect without a username/password (guest access)

• uid=99 = treat files as owned by local user ID 99

• gid=100 = treat files as owned by local group ID 100

• _netdev = wait for network before mounting

• noatime = don’t update “last accessed” timestamps

• noserverino = don’t use server inode numbers (avoid inode-related issues)

• noperm = don’t enforce local Linux permissions; let the server decide

• cache=none = disable client-side caching (reduce stale reads)

• x-systemd.automount = mount on first access, not at boot

• x-systemd.idle-timeout=600 = unmount after 10 minutes of inactivity

• exec = allow running programs from the mount

• final 0 = don’t include in dump backups

• final 0 = don’t run fsck checks on it

Change the above for your requirements.
I also create a dedicated “Unraid” identity on the Linux box so UID/GID 99/100 are clearly identifiable when you do ls -l:

# make sure group 100 exists (name it whatever you want)
groupadd -g 100 unraid
# create a system user with no home and no shell, pinned to UID 99 / GID 100
useradd -u 99 -g 100 -M -r -s /usr/sbin/nologin unraid

Then run the following:

mkdir -p /mnt/<mountpoint>
systemctl daemon-reload

Sanity checks (make sure the required systemd targets/units are active):

systemctl is-enabled remote-fs.target
systemctl is-active remote-fs.target

(Optional) If you want to confirm systemd actually created the automount unit:

systemctl list-units --type=automount | grep -F "<mountpoint>"

Important note about automount: x-systemd.automount is mount-on-access. It will NOT mount the share until something actually touches the mountpoint. So if you do this and then run df, you’re not going to see anything yet, that’s expected. df will only show it after the mount is triggered.

Now trigger the mount by accessing the directory:

cd /mnt/<mountpoint>
# or:ls /mnt/<mountpoint>

After that, df should show the mounted share.

You are a hero!! You explained the process clearer than any of the guides I found. Mounted a share and it worked perfectly. And with the serverside SMB config it creates everything as it should!! (also I added a link to your post to the comments of my fstab for future reference :D)

Thank you both so much!!

Edited January 14Jan 14 by Sam_Axe

Quick follow-up here. I've since removed "cache=none" from my mounts as during heavy writes to the NAS I was getting abysmal throughput. The default setting of "cache=strict" is good enough for the bast majority of users.