(6.9.2) Files Within Share Only Accessible By User Account Who Wrote Them

[Evenimous]

The title explains the problem... but let me give a bit more context.

 

There are five user accounts that will be accessing this particular share. This share is set to:

Export: Yes, Case-sensitive names: Auto, and Security: Secure.

 

In the unraid GUI, under the share's security settings, every one of these accounts has been set as read/write capable for this share. They are all perfectly able to access the share via a mapped network drive in windows 10, and are able to read/write as they please, with the exception of this. Say for example, user "John" writes a file to /mnt/user/path/to/folder, and then user "Brad" goes to access this file. This file is not even readable for the "Brad" user, even though both of them should have full read/write access to this share.

 

I figured that this may have been a configuration issue, so I went into the terminal, CD'd to the appropriate location, and then ls -la to check the ownership and permissions on the folders and files within /mnt/user/path/to/folder. The folders/files that were problematic were said to be "-rw-rw----+" in terms of permissions, and rather than being owned by "nobody users", was owned by "John users" 

 

To me, this means that they are all in the "users" group from Unraid, and thus "Brad" should have "rw" access to the folders/files created, at the very least. 

 

So, why can't "Brad" read and write to this file, and why does "John" own the files/folders they wrote, rather than the "nobody" user? How may I make it such that the files written are accessible in the manner I have configured in the GUI?

[Evenimous]

I used two commands in the terminal to try to understand the users and the groups in UnRaid;

> cat /etc/group
> cat /etc/passwd

 

Output for the first command, excluding unnecessary info, was as follows;

> users:x:100:        <-- Indicates to me that no users are a part of this group? should see something like "users:x:100:john:brad:" to show that they are part of that group

 

and for the second command, was as follows;

> brad:x:1004:100::/bin/false

> john:x:1005:100:descriptioon:/:/bin/false    <-- Indicates that both users are in group "100", which is users.... does not explain why they are not shown as part of the group or act like they are part of the group

 

[JorgeB]

Cannot reproduce this, all looks the same as you describe, including this:

15 hours ago, Evenimous said:

> users:x:100:        <-- Indicates to me that no users are a part of this group?

but works correctly, files copied by one user are owned by that user but a different one can read and write them, please try creating a new test share with the same settings to see if it's any different.

[Frank1940]

On 4/18/2023 at 8:26 PM, Evenimous said:

he folders/files that were problematic were said to be "-rw-rw----+" in terms of permissions,

See here:

 

        https://www.linuxquestions.org/questions/linux-newbie-8/what-is-in-drwxrwxrwx-915243/

and

        https://forums.unraid.net/topic/116389-access-denied-printer-unraid-share/?tab=comments#comment-1059803

 

How are these files being written?  It does not seem to be with SMB.  Does some Docker or VM have direct write access to the array?  (I know that some Dockers have variables that can be setup to control some things are write permission masks, User ID and Group ID.  You do have to be careful when you setup direct access to the array that you get these things set up correctly. Unraid SMB expects that the group will be users --- ID number of 100.  The name of the owner does not matter for access via SMB.  I do not know what the situation is via NFS...)

 

From another thread discussing SMB security:

Quote

 

Recently, something has come to my attention about Unraid and SMB. There have been incidences where access to Unraid shares is restricted or blocked completely from users who should have access to it. What has been found in these cases is that a feature, has been enable on the Unraid side, called Access Control Lists (ACL for short). This will show up as an ‘+’ at the end of the Linux permissions. See the screen capture below:

 

Note that the ‘+’ is also on the file as well as the share/directory.   ACL changes the way that Linux is going to control access to these resources. After some research, I found out that Windows has used ACL for a long time.  The SAMBA group has added ACL into its version of SMB.  Unraid does not use ACL in its security scheme.

 

At the present time, I can think of only one way that a ACL could be found on any Unraid server. It was done by a Windows user who was trying to change how SMB worked by applying Windows security features to an Unraid share by changing the default Security settings. (Basically, right-clicking on the Share in Windows Explorer, selecting ‘Properties’, then the ‘Security’ tab and working from there.)

 

The point I am making is that you can’t fix a share access problem by trying to change a Unraid share security using Windows security tools on that share. If you try, you will probably make things worst! (Unless you are a Windows SMB Networking Guru…) It is important to realize that if you are denied permission to an Unraid share resource, the problem can only be fixed on the Unraid side using the Tools in the Unraid GUI (or via the command line for specific problems).

 

 

 

 

Edited April 20, 2023 by Frank1940

[JorgeB]

12 minutes ago, Frank1940 said:

he folders/files that were problematic were said to be "-rw-rw----+" in terms of permissions,

 

Yes, thank you @Frank1940, I missed that the permissions are wrong and different from what I got, files were written over SMB (Win10) and the permissions are all:

-rw-rw-rw-

folders are all

drwxrwxrwx

 

 

 

 

[Frank1940]

@Evenimous, you are not using AD (Active Directory) in your SMB setup are you?   IF you are, you  probably want to look through this subforum:

 

       https://forums.unraid.net/forum/102-active-directory/

[Evenimous]

Thank you @Frank1940and @JorgeB for your thoughtful comments. I was already on the right path yesterday and found the source of my issue, which was actually exactly what you two had guessed.

 

Previously, I had set up my UnRaid server to use active directory, though I recently switched off of it due to poor implementation. To my understanding, what that would have added in are more granular ACLs, controlled by the active directory administrator, rather than by UnRaid. After I learned what the "+" meant, and how to check ACLs with getfacl, I found my solution, which you may read below.

---------------------------------------------------------

 

As mentioned in my initial post, the permissions were set to "-rw-rw----+", with "+" indicating that there is an access control list for the directory. To me, this means that the "users" group could potentially have "---" permissions within this ACL, which, once I checked, there was.

 

Command used at terminal;

> getfacl New\ folder    <-- created "new folder" as "brad" user in windows

 

Summarized response from terminal;
> "group:users:---"         <-- Previous assumption that the ACL was blocking was correct

 

So, to fix my problem, I need to properly set the ACL. I first tested this within a test share, set to "secure" with all users given read and write perms, as follows.

> cat /etc/group        <--- Used to find what the GID is of the "users" group

> users:x:100:            <--- GID is "100", which will be used in setfacl

 

Map test share as "brad" on device. Create folder named "folder" via windows file explorer. Check ACL via terminal on server

> cd /mnt/user/testshare 

> getfacl folder   

 

Response below: 

---------------------------------------------------------

user::rwx
user:nobody:rwx
user:1590166004:rwx
group::---
group:users:---
mask::rwx
other::---
default:user::rwx
default:user:nobody:rwx
default:user:1590166004:rwx
default:group::---
default:group:users:---
default:mask::rwx
default:other::---

---------------------------------------------------------

 

Note how there is a user with a bunch of numbers. this is the active directory administrator. I'm simply going to ignore that user for now, as the admin should have perms anyways. The problem currently lies with "group:users:---", disallowing the users group from accessing the folder. Also, "default:group:users:---", which will make this non-access ACL propogate whenever new folders are created. I then changed the default ACLs and the ACL for the folder to allow the "users" group access with the two following commands:
> setfacl -m g:100:rwx folder         <--- Sets the users group on the folder to be allowed read, write, and execute
> setfacl -d -m g:100:rwx folder     <--- Sets the users group to be allowed by default on this folder, and any content created within the folders.

 

Now we check the ACL of the folder to see if everything is alright.
> getfacl folder

 

Response below: 

---------------------------------------------------------

user::rwx
user:nobody:rwx
user:1590166004:rwx
group::---
group:users:rwx
mask::rwx
other::---
default:user::rwx
default:user:nobody:rwx
default:user:1590166004:rwx
default:group::---
default:group:users:rwx
default:mask::rwx
default:other::---

---------------------------------------------------------

 

Everything seems good, so I mapped the test share as user "John" and was able to read and write from the folder that Brad had created, and when I went on my other system previously set up for Brad, he was able to read and write anything John had created. All works well. So, now I just have to recursively write ACL changes to any of the shares experiencing the problem, aka all of them. Before I do that, I want to make sure I know how to do this recursively correctly, so I went into the test share again, and made a new file called "testfolder", and within that, a folder called "recursivefolder", and a file within that called "recursivefolderfile.txt". Then, I went back to my terminal and tried the following commands;

---------------------------------------------------------

 

>setfacl -d -Rm g:100:rwx testfolder    <--- I had previously messed up putting the "R" elsewhere. It must be BEFORE the modifier "m", or it won't work. Not sure why.

>setfacl -Rm g:100:rwx testfolder        <--- Must also set the non-default, or the current. This will apply to the files within the folder, as those don't have defaults, they simply inherit them.

 

>getfacl testfolder                                                           <--- All good, as my previous fix above.

>getfacl testfolder/recursivefolder                                    <--- All good, recrusive functionality is working for folders

>getfacl testfolder/recursivefolder/recursivefolderfile.txt   <--- All good, recursive functionality worked for files too.

 

---------------------------------------------------------

 

Now I recursively set this on my actual use folders, using the setfacl commands "setfacl -d -Rm g:100:rwx [foldername]" and "setfacl -RM g:100:rwx" after cd /mnt/user. This solved my problem.

 

---------------------------------------------------------

 

Another potential problem that I realized is that /mnt/user was causing any new shares created to inherit these incorrect ACLs, so I changed that as well. I don't want any non-authenticated users to be able to access data on my unraid server, so other will be set to --- for my setup.

 

> cd /mnt                                  <-- Places us in the easiest spot to write the next command

> setfacl -d -m g:100:rwx user    <-- Fixes the "user" shares area of UnRaid for future use. Essentially will be "Secure" for any shares created. 

 

 

 

Edited April 20, 2023 by Evenimous
forgot to add a command I used near the bottom, added that in for clarity