Can someone please point me to what might be going wrong on my server? For a long time, I was exclusively using smb file shares to cater for the variety of clients that would access the server (Linux desktop, Apple Mac, Windows, iphone, Android). Recently I noticed that mover wasn't working for some files/folders and that they would remain in the cache drives. It would appear that this was being caused by file/folder ownership (not 99:100, but the file creator and users group eg 1000:100). Furthermore, folders that were being created had rwxr-xr-x permissions, while files had rw-r--r--. I fixed the problem with Docker Safe New Perms, but I noticed that issue persisted with new files after I ran it. Additionally, a couple of the shares started disappearing from my remote network mount list on my Linux desktop whenever I created a file or folder in the share, and I would need to unmount and remount it to gain access again.

Thinking that it might be a samba issue, I enabled nfs and exported it on a few shares with private security and added my Linux desktop to the acl with the rules async,no_subtree_check,rw,sec=sys,insecure,anonuid=99,anongid=100,no_root_squash; when I created a file, it was 1000:1000 with rw-r--r-- and a folder was 1000:1000 and rwxr-xr-x. Changing the rules to async,no_subtree_check,rw,sec=sys,insecure,anonuid=99,anongid=100,all_squash; when I created a file/folder, it gave ownership to 99:100, but the permissions were still wrong with rw-r--r--/rwxr-xr-x.

FWIW, I was mounting the SMB shares on my Linux desktop via systemd (now all disabled) and mounting the nfs shares with /etc/fstab.

nabu-diagnostics-20260128-2145.zip

If the files are getting created with the wrong permissions over SMB, it suggests the problem is on the client side, since you don't need (don't have) the option to set those in Unraid

Possibly the Linux desktop SMB mount is enforcing its own UID/GID and umask, overriding Unraid’s Samba defaults.

This can be caused by systemd mount options like: uid=1000,gid=100,dir_mode=0755,file_mode=0644 or by mfsymlinks, noperm, or missing noperm.

Try something like

//server/share /mnt/share cifs \

credentials=/root/.smbcred,iocharset=utf8,vers=3.1.1,noperm 0 0

Do not specify:

uid=

gid=

file_mode=

dir_mode=

Let Samba handle permissions entirely.

That didn't fix the issue I'm afraid. Digging deeper, other users on Windows and Mac clients are experiencing the same problems, so it would appear that there is something at the server end that is causing this issue. Have you any suggestions how to address this?

Unraid doesn't have any setting to change that, if they are getting changed, it suggests some change was made by you, a plugin, etc,

You can try redoing the flash drive, backup the current one first and then recreate it using the USB tool and just restore the bare minimum, like the key, super.dat and the pools folder for the assignments, also copy the docker user templates folder (\config\plugins\dockerMan\templates-user), if all works you can then reconfigure the server or try restoring a few config files at a time from the backup to see if you can find the culprit.

First for some information for SMB/Samba, read this thread:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/

Next thing-- Post up a screen shot of the output of this command

testparm

This part is needed as it shows the options/parameters that have been changed from the Samba defaults:

Note that you have to press <ENTER> to get the listing.

(If you copy-and-paste the output, please format it it as " </> Inline Code" before posting. It is a option listed under the '...' in the posting entry toolbar. )

On 1/28/2026 at 4:48 PM, Boyturtle said:

Recently I noticed that mover wasn't working for some files/folders and that they would remain in the cache drives. It would appear that this was being caused by file/folder ownership (not 99:100, but the file creator and users group eg 1000:100). Furthermore, folders that were being created had rwxr-xr-x permissions, while files had rw-r--r--. I fixed the problem with Docker Safe New Perms, but I noticed that issue persisted with new files after I ran it. A

nabu-diagnostics-20260128-2145.zip

The Gurus for Linux security have 'recently' (apparently) suggested that directory permissions be 755 and File permissions be 644. Since then some(?)/many(?) Linux distributions have implemented these recommendations. Unfortunately, these permissions do not work with Unraid!

This is how one addresses this issue when dealing with Docker containers:

https://forums.unraid.net/topic/188600-share-permissions-changed-to-owner-99/#comment-1540351

Notice that virtually all Docker containers use Linux and write directly to the Unraid file system using the Linux API's. If the Linux distribution that the container is using the new permissions, it has be told not to use them when writing to the Unraid file system.

With a free standing client, the Linux client that is using NFS to write directly to Unraid shares is going to be using the defaults defined for that distribution unless it is told to use other permissions. I am not sure if how you have to set up other OS to have proper access to Unraid shares using NFS but you will have to make sure it is using 777 and 666.

If you are using Samba from any client (Windows, Linux, Unix, Android, etc.), you definitely do not want to be setting any permissions from the client side. Let Unraid's Samba configuration handle that. Remember that you need to log in using an Unraid 'Shares Access' user that you have previously setup on Unraid.