SMB Permissions issues on either shares, folders or files

[Maginos]

Hi guys,

I have strange permissions issues with my unraid servers and I'm searching for help to fix this permanently.

 

90% of the time, everything works fine with my SMB shares, but sometimes I can observe the following:

When I click on a share on my Win PC, I get an error message that I don't have permission to enter this share. The same can occur not only with shares, but also with folders or files within the share. So the permission error can occur either by clicking on a share, folder or file.

 

I found, that this issue can be resolved by using the "New Permissions" functionality on unraid.

But since this is occuring every few weeks and I would like my father to access his files on the server without me resetting the permissions, I would like to solve this permanently.

What the "New Permissions" function does, it sets the user/group to nobody/users and the directories to 777, the read/write files to 666 and the read only files to 444.

So the troubleshooting could begin with following commands:
 

find /mnt/user/share -type d -not -perm 777

find /mnt/user/share -type f -perm 644   or

find /mnt/user/share -type f -not perm 666 -o -type f -not -perm 444

 

The first commands searches for all directories on the share that don't have 777 permissions, the second one searches for all files with permission 644.

As of my understanding, the second number can not be 4 or less, or the smb user has no access to the directory/file.

 

The first command is actually very useful, since there are only a few lines of output.
 

The found folders were created by paperless-ngx:

 

/mnt/user/home_florian/Dokumente/3_Media/documents/originals/Eduard Eberle/2024
/mnt/user/home_florian/Dokumente/3_Media/documents/originals/Sonstiges/2024
/mnt/user/home_florian/Dokumente/3_Media/documents/originals/Agentur für Arbeit/2024
/mnt/user/home_florian/Dokumente/3_Media/documents/archive/Eduard Eberle/2024
/mnt/user/home_florian/Dokumente/3_Media/documents/archive/Sonstiges/2024
/mnt/user/home_florian/Dokumente/3_Media/documents/archive/Agentur für Arbeit/2024

I have no idea what the problem with these folders is. The folders with 2023 at the end have all the correct permissions and all other folders from paperless-ngx too. So why have these folders other permissions than the others?

 

 

The command

find /mnt/user/share -type f -perm 644

 

is actually much more helpful than

find /mnt/user/share -type f -not perm 666 -o -type f -not -perm 444

Here's the reason why:
I found out, that I have files with permissions 766 on the server (I don't know why these files have these permissions... All of them were uploaded via SMB and not via my Nextcloud) and these also contribute to the output.

When I search specifically for files with 644 permissions, I get files which were upload by the following applications:

 

- Notability (note taking App on my iPad, upload via WebDAV)

- Thunderbird (via Nextcloud mail attachment, upload also via WebDAV)

- Paperless-ngx again (upload through Paperless-ngx itself, locally)

 

It is worth noting, that NOT ALL FILES which were uploaded from these applications have wrong permissions, only a few.

I also have a nextcloud connected, which has access to the same data. I use the linuxserver container and the shares on my unraid server are mounted with -v option in the linuxserver container.

 

 

The issued that my dad had today was, that he wasn't able to access a folder on his share because of this permission issue. After setting new permissions, everything was fine.

He accesses this folder only on this PC via SMB and not on his mobile phone. The last time, he edited a file in this folder was some months ago and this was again via SMB.

 

 

 

As you can see, I am able to find what causes the problems for the wrong SMB permissions error, but I don't understand why only a few files and folders are affected and why only they get the wrong permissions.

 

I resetted the permissions with "New permissions" several time, but after some time, they occur again.

Can anyone help me with this?

Thank you for your help!

 

Maginos

 

[Frank1940]

OK are these Docker containers?

 

If so, read this post:

 

      https://forums.unraid.net/topic/131730-update-from-69-to-6115-and-got-permission-denied/#comment-1219731

 

Pay particular attention to this section:

 

 

New Permissions will probably be required after you have gotten them all changed.  (Many Dockers containers that are not Unraid aware often are configured to set things up wrong.  I would hope that any Unraid developer would take the time to modify his containers to do things correctly.)

[Maginos]

For the issues with Nextcloud and Paperless, this could be the solution indeed.

I started the "Docker Safe New Permissions" at around 7:45 a.m. CET and it's still running. Since PID and PUID were already set for both containers, I only added the UMASK to the containers.

What I don't understand is, why the permissions of the folder of my dad changes. He said, he edited a file in this folder a few months ago and didn't access it since then. Yesterday the folder had 644 perms and he was not able to access it. But why does that happen?

[Frank1940]

6 minutes ago, Maginos said:

He said, he edited a file in this folder a few months ago and didn't access it since then. Yesterday the folder had 644 perms and he was not able to access it.

Permissions in Linux work differently on directories than they do for files!  Read this entire article:

 

      https://www.redhat.com/sysadmin/linux-file-permissions-explained

 

 

8 minutes ago, Maginos said:

But why does that happen?

Not sure.  You have to know what OS he used.  You would have to know the steps he did when he edited that 'file'.  You would have to know if he used SMB, NFS or what did the permissions on the file end up as?

 

BTW, this type of permission problems are seldom encountered by Unraid users.  They are caused by systems external to the Unraid base OS.  Sometimes, these external system are Dockers containers that are not properly set up for use with Unraid and, sometimes, it is cockpit error.

[Maginos]

Ok thank you, I will read the ENTIRE article.

He uses Win 10 and a office program like LibreOffice to edit a .doc or .odt file. He uses SMB and uses the SMB credentials for his registered user in unraid.

[Frank1940]

8 minutes ago, Maginos said:

Ok thank you, I will read the ENTIRE article.

He uses Win 10 and a office program like LibreOffice to edit a .doc or .odt file. He uses SMB and uses the SMB credentials for his registered user in unraid.

 

Make sure he is not using the 'Sharing' and 'Security' Tabs under properties to 'fix' permissions on directories and files that are on the Unraid server.  (There aren't many people in the world who can give proper advice on how to do this and they work as paid consultants getting the 'big bucks'!)   You can find info on setting Unraid up for a secure environment here:

 

     https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/#comment-1009109

 

 

 

Also, the 'Help' feature in the Unraid webGUI will explain the difference between the 'Public', 'Secure' and 'Private' share settings.   The combination should provide all the protection that most home LANs require.  Unraid does provide a encrypting feature if that is deemed necessary for some reason.  

[Maginos]

5 minutes ago, Frank1940 said:

Make sure he is not using the 'Sharing' and 'Security' Tabs under properties to 'fix' permissions on directories and files that are on the Unraid server. 

He doesn't.

He tells me, that he doesn't have access to his files and I reset permissions with the "New Permissions" feature within unraid. That's all. And this seems to be enough for a temporary fix.

 

All SMB shares, where "Export" is switched to "yes", have the security setting "Private". 

[Frank1940]

No other ideas. 

[Maginos]

Thank you for your help so far!

Do you think it might help switching the Office software from LibreOffice to OnlyOffice? Shouldn't make a difference, but since it seems to be a WIN 10 related issue, thats all what comes to my mind.

[Frank1940]

I use LibreOffice but only local files on my PC and only the Writer and Calc modules.  I had a very quick look and there may be some sort of File Manager for remote files.  (I didn't explore it. but usually these only allow basic file browsing.)

[Maginos]

I found this.

 

I'm relatively sure, that my dad did not open files from the SMB share like this. Instead, he just goes to the SMB share and double clicks on the file and it opens in Libre Office. Maybe this is responsible for the permissions issue. I will try later.

[Maginos]

Ok, I did some research, here the results:

- It's not possible to open a file on an SMB server like described in the link, the "Windows Share" option is missing completely.

- My father edited yesterday 6:44 p.m. the file /mnt/user/sharename/A/B/filename.doc. Already today, the folders /mnt/user/sharename and /mnt/user/sharename/A/B/ had wrong permissions again. I resetted the permissions yesterday before 6:44 p.m. So today I resetted the permissions again.
 

- Then I opened a .odt file from the /mnt/user/sharename/ folder via SMB, edited and saved it. What I can observe is, that the file gets following permissions:
 

 -rwxrw----+ dads_username:users

So it gets extended permissions. Using the

getfacl

command on this file reveals the following:
 

owner: username_of_my_father
user: nobody:rwx           #effective: rw-
group:: ----
group:users: ----
group:NT\040Authority\\anonymous\040logon:rwx
group:3007:rwx
mask::rw-
other::---

 

This seems to be correct at first glance. 

When new .odt files are created in the /mnt/user/sharename/ folder via SMB, they all get these extended permissions. 

So right now, everything seems to work as expected. I hope the problem is fixed with this, but we will see.

 

I also saw some .~lock.filename.odt files in the folder which were not deleted for whatever reason. They also had the permissions from above, so they shouldnt be the problem.

 

[Frank1940]

This area of the extended permissions is a bit of a mystery to me.  What I do know is that they have a tendency to screw up Unraid SMB access.  (Not sure what they do to NFS access...)   You probably need to Google to find more out.  

 

I know that I have edited my Wife's LibreOffice files on her computer from my computer and have not had an issue to date.  (Knock on wood...)

 

As you read, if it is turning the execute bit on a directory, you will not be able to access the files within that directory. 

[Frank1940]

Quick Test:

 

LibreOffice  7.3.5.2

Windows 11  23H2

Unraid  6.12.8

 

 

First test --- copied   2023\ HolidayAlbum.odt   to server  using Windows File Explorer.  Used GUI terminal and   ls   program to verify permissions.  

        Permission were   rw-rw-rw-   as expected.

        Opened file by doubleclicking in Windows Explorer.  Edited in LibreOffice.  PErmissions changed as shown above

        Everything worked as expected.

 

Second test--  Using LibreOffice, New document

                      Than created directory  Libreoffice  using 'Save as' from Writer.

                      Save New.odt in that new directory.

                      Permissions as shown below.  Note they are what one would expect with the exception of the execute bit.

 

Third test---  Reopened the above file to edit it.  These are the permissions in that state:

                  Notice that extended attributes have been attached when the file was locked!

                  Edited the file and save it. Closed LibreOffice.

                  This is the permissions after that:

 

I run a series of tests and I had no problems access the directories using Windows Explorer.  I even opened the New.odt with an E-book reader and that was successful. 

 

Third test-- I  opened this file using Windows Explorer from another computer logged in with different user-name.  Edited the file and saved it.

                 Here are the results from that test:

 

So you see that Libreoffice does work with Unraid SMB.  The fact that there are extended attributes on LibreOffice edited files does not seem to impact normal usage of these files.  I have no idea why your dad is running into issues.  But I would suspect that it is something in the way that his Windows computer is set up.  I will ping @dlandon as he does seem to have a bit more knowledge in this area. 

 

                     

 

[Maginos]

Ok, thank you for your tests. I don't know why your permissions look different than mine, but ok. So if the permissions of the .odt files are correct, why do the permissions of the folders change? That's what I don't understand.

 

I don't know if this is important, but to improve the SMB performance under macOS, I added these lines under Settings --> SMB Settings --> SMB Extras:
 

veto files = /._*/.DS_Store/
aio read size = 1
aio write size = 1
strict locking = No
use sendfile = No
server multi channel support = Yes
readdir_attr:aapl_rsize = no
readdir_attr:aapl_finder_info = no
readdir_attr:aapl_max_access = no
fruit:posix_rename = yes
fruit:metadata = stream

 

[Frank1940]

3 hours ago, Maginos said:

Ok, thank you for your tests. I don't know why your permissions look different than mine, but ok. So if the permissions of the .odt files are correct, why do the permissions of the folders change? That's what I don't understand.

 

To find out, you will have to perform a similiar series of tests using that Windows computer to see if you can figure out what is causing it. 

 

3 hours ago, Maginos said:

I don't know if this is important, but to improve the SMB performance under macOS, I added these lines under Settings --> SMB Settings --> SMB Extras:

 

I don't either but there is a warning here:

 

And here is a link to what those lines are doing:

 

     https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

 

By the way, if you put a    #     in front of any line in SMB Extra settings, you will convert it into a comment...

 

I have no experience with Apple products so I am no help there at all.

 

[dlandon]

12 hours ago, Frank1940 said:

I will ping @dlandon as he does seem to have a bit more knowledge in this area. 

Give me some time to review this post.

[Maginos]

Good morning guys, unfortunately, the issue with my dads folder is not fixed. The folder had these permissions again today:
 

drwxrwx---+ 1 nobody users    52 Mar 24 09:44 foldername

 

He has not edited anything in this folder since I set new permissions the last time. So maybe the problem is within unraid? I checked my User Scripts, but no script accesses this folder.

The only thing that comes to my mind is my backup script, which runs at Saturday 1 a.m.

My unraid server is in a DMZ and my Openmediavault server is in my LAN. So the OMV Server has to pull the data from the unraid server. This is done with this command:
 

rsync -avhe 'ssh -p PORT' [email protected]:/mnt/user/sharename/* /srv/dev-disk-by-id-dm-name-name/backup/sharename --exclude='foldername'

 

For what I have read, rsync doesn't change the permissions on the source, so this should also not be a problem. Within the -a option of the rsync command, the -p otion is included, which ensures, that the permissions of the source file is not changed.

Or am I missing something?

 

[Frank1940]

1 hour ago, Maginos said:

My unraid server is in a DMZ

This is usually bad news!   Unraid is not intended to be run a DMZ and it is usually hacked if it is.   You should be using a VPN...

[Maginos]

I think you want wo warn me from having unraid as an exposed host, which I don't have. The GUI of unraid is not accessible from the internet.

 

What I intended to say is, that the unraid server is in a seperate network, which doesn't have access to any other network than the internet. And only all outgoing connections are allowed. The web applications I host on the server are behind a Web Application Firewall on my Sophos UTM, so this should be fine.

[dlandon]

I want you to try a SMB Extras setting and see if it helps with the permissions issue.  Add the fiollowing line:

force user = nobody

in the SMB Extras on the Settings->SMB page.

 

This should force all users on SMB shares to be treated as 'nobody' for both reads and writes.

[Maginos]

I did that, thank you. I will report back, if this solves the problem.

I created a .docx file via SMB on a share and it got following permissions:
 

-rwxrwxrw-+ 1 nobody users     13280 Mar 24 14:59 TEST\ (2).docx*

 

The getfacl command gives following output:

# file: mnt/user/sharename/TEST (2).docx
# owner: nobody
# group: users
user::rwx
user:nobody:rwx
group::rw-
group:users:rw-
mask::rwx
other::rw-

So should be fine.

 

Thank you for your help dlandon. 👍

[Maginos]

Hi guys,

 

unfortunately, I have bad news. The error came back and the permissions of the folder /mnt/user/sharnename/foldername changed again:
 

drwxrwx---+ 1 nobody users    62 Mar 29 10:45 foldername

 

User and group are ok, but the permissions are different to the other folders. All other folders on the share have

drwxrwxrwx

or

drwxrwxrwx+

permissions.

 

getfacl /mnt/user/sharename/foldername

getfacl: Removing leading '/' from absolute path names
# file: mnt/user/sharename/foldername/
# owner: nobody
# group: users
user::rwx
user:nobody:rwx
group::---
group:users:---
group:NT\040Authority\\anonymous\040logon:rwx
group:3007:rwx
mask::rwx
other::---
default:user::rwx
default:user:nobody:rwx
default:group::---
default:group:users:---
default:group:NT\040Authority\\anonymous\040logon:rwx
default:group:3007:rwx
default:mask::rwx
default:other::---

 

This is the output from the getfacl command.

Do you have any other ideas?

Thank you once again!

[dlandon]

Post a new diagnostics.

[Maginos]

Here are the diagnostics.

tilda-diagnostics-20240329-1334.zip