SMB permissions seemingly not working correctly

[FlexibleToast]

I've been using file shares and samba for many years at this point, but I'm new to Unraid. I've copied over everything from my old OMV based NAS and I'm trying to set things up now. For some reason my different shares have the exact same settings and permissions, but they have different behaviors and it doesn't make any sense to me. Unraid has a user that is the same name as my Windows 11 username. I have two shares, one is 'download' the other is 'media.' They both have a file in them that I've tried to rename.

 

On the media share I get an error saying I need permission from nobody to make changes to the file. The media share is set to 'Secure' and my user has 'Read/Write' access. The file has the following permissions:

 

root@kerbol-next:/mnt/user/media/Movies/Rebel Moon - Part One A Child of Fire (2023)# ls -l
total 1825733
-rw-rw-rw- 1 nobody users 1882551183 Dec 14  2023 Rebel\ Moon\ -\ Part\ One\ A\ Child\ of\ Fire\ [WEBRip-1080p].mkv

 

The read/write seems to work because I can create and delete a file in that same directory, but I can't rename that file.

 

On the download share I can rename a file without any issues. The download share is also set to 'Secure' and my user has 'Read/Write' access. The file has the following permissions:

root@kerbol-next:/mnt/user/downloads/complete/movies/The.Voyeurs.2021.1080p.UHD.WEBRip.HDR.x265.DDP5.1-SM737# ls -l
total 3543540
-rw-rw-rw- 1 nobody users 3631161077 Jul  6 03:58 The.Voyeurs.2021.1080p.UHD.WEBRip.HDR.x265.DDP5.1-SM737.mkv

 

The biggest difference I can think of is that the media share is on the array and downloads is on my cache pool. I made a copy of the file in media so that way it would be in cache pre-move and set the same permissions; that file also would not let me rename it... What else could be different between the two shares that allows me to rename the file on one but not the other? I suppose I should mention this is Unraid 7.0.0-beta.2.

[Frank1940]

1 hour ago, FlexibleToast said:

The biggest difference I can think of is that the media share is on the array and downloads is on my cache pool. I made a copy of the file in media so that way it would be in cache pre-move and set the same permissions; that file also would not let me rename it.

 

Do You have two copies on the file in the media share---  One on the cache drive and the other on the array?

 

One other thing to check is the permissions, owner and group for each directory in the path from   /mnt   down to the directory containing the file.

 

The group is the most important one as the group is what your 'Share Access user' will be using for access.   (All 'Share Access users' are members of the   users    group...)

[FlexibleToast]

39 minutes ago, Frank1940 said:

 

Do You have two copies on the file in the media share---  One on the cache drive and the other on the array?

 

One other thing to check is the permissions, owner and group for each directory in the path from   /mnt   down to the directory containing the file.

 

The group is the most important one as the group is what your 'Share Access user' will be using for access.   (All 'Share Access users' are members of the   users    group...)

1. No, just one copy that is now on the cache drive because I copy/pasted it as part of a test so it is a 'new' file that hasn't been moved by mover yet.

 

2. Doing this walk I did find the problem. The difference is the mode of the directory. Notice for the one I can't rename it is '7777' the one I can rename is '0777'. It was the sticky bit doing its job preventing any user that isn't the owner or root from deleting or renaming the files in the directory. I have no idea how that got set... Neither 'New Permissions' or the 'Docker Safe New Permissions' seems to set the sticky bit. With all the rsync'ing and what not I've been doing I guess it's not too surprising something weird got set though. Even after years of being a linux admin sometimes something basic will bite you, lol. Thanks for the help.

root@kerbol-next:/mnt/user/media/Movies# ls -l | grep Rebel
drwxrwsrwt 1 nobody users 3 Aug 13 20:20 Rebel\ Moon\ -\ Part\ One\ A\ Child\ of\ Fire\ (2023)/
drwxrwsrwt 1 nobody users 3 Aug  7 00:26 Rebel\ Moon\ -\ Part\ Two\ The\ Scargiver\ (2024)/
root@kerbol-next:/mnt/user/media/Movies# cd ..; ls -l | grep media
drwsrwsrwx 1 nobody users  4 Aug 13 19:56 media/
root@kerbol-next:/mnt/user# ls -l | grep downloads
drwxrwxrwx 1 nobody users  6 Aug  8 14:09 downloads/
root@kerbol-next:/mnt/user# cd downloads/; ls -l | grep complete
drwsrwsrwt 1 nobody users 10 Aug 13 14:36 complete/
drwsrwsrwt 1 nobody users  2 Aug 13 14:36 incomplete/
root@kerbol-next:/mnt/user/downloads# cd complete; ls -l | grep movies
drwsrwsrwt 1 nobody users     3 Aug 13 00:19 movies/
root@kerbol-next:/mnt/user/downloads/complete# cd movies; ls -l
total 33
drwxrwxrwx 1 nobody users 3 Aug 13 19:55 The.Voyeurs.2021.1080p.UHD.WEBRip.HDR.x265.DDP5.1-SM737/

 

I've fixed this issue by running `chmod -R ug-s,-t /mnt/user/*` and then running the 'Docker Safe New Permissions' tool. This will remove the SUID, GUID, and sticky bit from every file and directory managed by Unraid.

[Frank1940]

I know just enough about the inner workings of Linux file/directory permissions to make me really dangerous.  (I suspect you are more of an expert than me sinceyou are using   grep   in the command line...)   Having said that, as you have surmised, Unraid requires (in the SMB Workgroup mode)  that the permissions for directories be 777, files to be 666, and the group to be   users    for SMB to work properly.  (Not sure about NFS as I haven't used it for years!)

 

You have probably surmised by now, that something is setting (when created) or modifying the permissions.  Let me say if Windows is a suspect, you should not be modifying security permissions on a Windows mapped drive!  (I am assuming that you are not using Active Directory.) 

 

If you continue to have problems, post back with details about what you have found and I will ping a couple of fellows who might be able to shed some insights into what might be happening. 

 

One more thing, Try the   Dynamix File Manager   plugin.  It is a very powerful file manager for managing the data files/file_system in Unraid.  After installation, it is accessed through the GUI. 

[FlexibleToast]

Yes, I've been working with Linux/Unix for years. I actually work as a consultant for Red Hat and have my RHCA. I work with Ansible and OpenShift though so occasionally something like the sticky bit can throw me off still. When you say 777 or 666 you're implying 0777 and 0666. I know for sure on my OMV setup I set at least the SUID and GUID. Looking at my OMV it looks as though I actually set the permissions as '7770'. I wanted the SUID and GUID in order to make sure newly created files inherit the proper group and ACLs don't work with ZFS. On OMV I should have set the permissions to '6770'... Anyway when I rsync'ed it to the new Unraid it preserved those permissions and the 'New Permissions' tool doesn't touch the SUID, GUID, or sticky bit. Instead that tool uses the method I normally never use; this output was another piece to solving that puzzle:
 

Processing: /mnt/user/media
... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/user/media
... chown -R nobody:users /mnt/user/media
... sync

Completed, elapsed time: 00:00:32

It is adding and removing permissions instead of resetting them to something like '0777' or '0666', which might be a touch more difficult because you would have to make a distinction between a directory and a file. Find could do it easy enough, but it would take longer.

 

TLDR: The issue was copying faulty permissions and the permissions tool not acting the way I assumed it would. Everything with those permissions should be good now. Now the next problem is Nextcloud.

[Frank1940]

2 hours ago, FlexibleToast said:

Yes, I've been working with Linux/Unix for years. I actually work as a consultant for Red Hat and have my RHCA. I work with Ansible and OpenShift though so occasionally something like the sticky bit can throw me off still. When you say 777 or 666 you're implying 0777 and 0666. I know for sure on my OMV setup I set at least the SUID and GUID. Looking at my OMV it looks as though I actually set the permissions as '7770'. I wanted the SUID and GUID in order to make sure newly created files inherit the proper group and ACLs don't work with ZFS. On OMV I should have set the permissions to '6770'... Anyway when I rsync'ed it to the new Unraid it preserved those permissions and the 'New Permissions' tool doesn't touch the SUID, GUID, or sticky bit. Instead that tool uses the method I normally never use; this output was another piece to solving that puzzle:
 

Processing: /mnt/user/media
... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/user/media
... chown -R nobody:users /mnt/user/media
... sync

Completed, elapsed time: 00:00:32

It is adding and removing permissions instead of resetting them to something like '0777' or '0666', which might be a touch more difficult because you would have to make a distinction between a directory and a file. Find could do it easy enough, but it would take longer.

 

TLDR: The issue was copying faulty permissions and the permissions tool not acting the way I assumed it would. Everything with those permissions should be good now. Now the next problem is Nextcloud.

 

I read through your explanation and because of my ignorance, I don't completely understand it.  rsync is a very powerful tool that can copy any Linux/Unix file system with all of file properties and permissions in tact!  BUT I am really concerned that New Permissions tool cannot fix it when the copied file system permissions don't meet what is required for Unraid.  As a result, I am pinging @limetech to bring this situation to his attention.  Granted that is an edge-case problem but it still one that needs to be addressed. 

[Frank1940]

On 8/14/2024 at 12:16 AM, FlexibleToast said:

I've fixed this issue by running `chmod -R ug-s,-t /mnt/user/*` and then running the 'Docker Safe New Permissions' tool. This will remove the SUID, GUID, and sticky bit from every file and directory managed by Unraid.

So you ran this command to fix the problem with the modified permissions for directories (and files) with the SUID, GUID and sticky bit.

chmod -R ug-s,-t /mnt/user/*

 

And LimeTech used this command in the New Permissions script:

 

Would this command do both jobs at the same time?

chmod -R ug-st,u-x,go-rwx,go+u,ugo+X /mnt/user/media

 

Or does the removal of the SUID, GUID and sticky bit have to be done separately?