Directory owner/group inheritance?

[Gizmotoy]

Hello,

 

I've been periodically been having trouble accessing certain files and directories on my unRaid server from various machines on my network.  I've tracked down that the issue appears to be caused by directory owner/group issues.

 

For example:

I have a machine with a user account on unRaid, and it logs into SMB shares via that username/password.  When files/directories are created as that user, they're owned by <username>:users.  The other machines on the network connect as guests with no username/password.  Files created from these machines get nobody:users.  Machines connected as guests can't modify files with permissions <username>:users.

 

I tried to force the unRaid user share to inherit the nobody:users permissions using "chmod g+s /mnt/user/<sharename>", but it didn't work.

 

Any idea how I can sort this out so everything plays nice together?

 

*Note: The reason I have a separate user account in this case is there are password-protected shares that only certain users can connect to.

[BLKMGK]

What version of unRAID? V5 has some issues with the version of Samba it shipped with and can be upgraded. Upgrading solved my permissions issues...

[Gizmotoy]

What version of unRAID? V5 has some issues with the version of Samba it shipped with and can be upgraded. Upgrading solved my permissions issues...

 

Sorry, yes, that's important information.  I'm running a 5.0rc2, which I'm aware is a few behind.  I keep thinking "just wait for final" and never get around to messing with it... 

 

Strange that it's Samba.  It seemed more like a Linux filesystem parameter issue than something application layer.

[Frank1940]

That is the way that Linux works (as I recall).  Once you start using users and login's, you are probably going to have to have a complete Linux setup with 'Owner', 'group' and 'other' permissions on every resource.  The nobody:users setup that unRIAD employs was developed to allow simple networks to be run without the  average Joe having to learn how to setup system permissions, owners, groups and all of the other minutia that goes with being a system administrator.  Of course, with the initial unRAID setup, every computer (and user) on the network has full read, write, create and delete privileges to every resource on the server.  It assumes that every user is trusted user... 

[Gizmotoy]

That is the way that Linux works (as I recall).

 

That's kind of what I'm getting at.  As I mentioned in the first post, in Linux you can run "chmod g+s /mnt/user/<sharename>" on a directory.  This forces every new file or directory below that to inherit the owner, group, and  permissions from the parent, no matter what user created the object.  However, this does not appear to be working.  I don't know if I misunderstand the command, or if there's something else wrong.

 

Edit:  Found that chmod g+s only causes group inheritance.  I still need user inheritance.  Trying to figure this out, now.  If anyone knows how to force user inheritance, I'd be interested to hear.

 

Or perhaps the better question is how to make it so the default user has full access to files created by other members of the users group.

[Frank1940]

That is the way that Linux works (as I recall).

 

That's kind of what I'm getting at.  As I mentioned in the first post, in Linux you can run "chmod g+s /mnt/user/<sharename>" on a directory.  This forces every new file or directory below that to inherit the owner, group, and  permissions from the parent, no matter what user created the object.  However, this does not appear to be working.  I don't know if I misunderstand the command, or if there's something else wrong.

 

Edit:  Found that chmod g+s only causes group inheritance.  I still need user inheritance.  Trying to figure this out, now.  If anyone knows how to force user inheritance, I'd be interested to hear.

 

Or perhaps the better question is how to make it so the default user has full access to files created by other members of the users group.

 

As I seem to recall, that user will to have root privileges.  Then they can do anything in the file structure regardless of the file permissions.  The question now is how to add root privileges to a user.  I know that with some Linux versions even the root user does not have root privileges unless they invoke it via the sudo command.

 

You could try adding root as a member of the group and see if you can log into the array. 

[Gizmotoy]

Is that true?  Users created in the unRaid UI have root privileges?  If that's the case, I'd rather reduce the privileges of that user than give guests root access.

 

As far as I'm aware, there's no need for that user to have root access.  Ideally it would behave identically to the guest users, with the exception that it has access to this one particular user share.

[dgaschk]

Linux has distinct ownership and permissions settings. unRAID does not use Linux permissions to restrict file access. The owner and owner permissions should not matter.

 

UnRAID handles security at the share level and this must be configured in the webGUI. The system does require that the Linux group permissions are correct. Assuming that share security is correctly configured, the files being created by <username> have incorrect group permissions. How are these files being created?

 

Correct permissions by running the "New Permissions" utility. Or enter "newperms target" where target is a file or directory.

[Frank1940]

Is that true?  Users created in the unRaid UI have root privileges?  If that's the case, I'd rather reduce the privileges of that user than give guests root access.

 

As far as I'm aware, there's no need for that user to have root access.  Ideally it would behave identically to the guest users, with the exception that it has access to this one particular user share.

 

NO!!!!  In general, they do NOT.  If you read carefully, I was saying that, with what you wanted to do, you would need a user who HAD root privileges.  What I can not recall is how to create such a user...

 

Of course, you could try logging into a share as root and see what happens....

 

 

You have to understand that there are three classes of permissions for every file and directory in Linux:  one set for the Owner,  The second set for members of the group and the third set for everyone else (commonly called "other").  unRAID sets (by default) files with  rw permission for the Owner, rw permissions for the group members, and no access for everybody else.  If you want anything but this standard setup, you are going to have to do a lot of research into the Linux permission system and into Samba to get everything configured to work the way you want it to.  (As a hint, most of the time, if you want a user to have read only permission, you should consider putting them  in the 'other' group.) 

[Frank1940]

Linux has distinct ownership and permissions settings. unRAID does not use Linux permissions to restrict file access. The owner and owner permissions should not matter.

 

UnRAID handles security at the share level and this must be configured in the webGUI. The system does require that the Linux group permissions are correct. Assuming that share security is correctly configured, the files being created by <username> have incorrect group permissions. How are these files being created?

 

Correct permissions by running the "New Permissions" utility. Or enter "newperms target" where target is a file or directory.

 

I don't believe this statement is completely true.  The Linux permissions are used by Samba and new files generated through Samba will set any Linux permission setup that the System Administrator wants.  Unfortunately, you will not be able to do this through the Webgui.  You are going to have to dig down into the guts of the system and modify the Samba configuration files at the command line interface using an editor such as vi to do the job.  I know I did a very simple setup on Ubuntu about six years and it took me a couple of weeks to get it working the way I wanted.  (The final setup worked almost identically to unRAID stock setup but Ubuntu required that I install Samba and then modify the stock configuration files to get it to work.) 

 

I do agree that getting all of the add-ins to write their using the nobody:users (owner:group) setup is the most desirable situation for most people. 

[Frank1940]

Hello,

 

*Note: The reason I have a separate user account in this case is there are password-protected shares that only certain users can connect to.

 

Where I am confused at the moment is where you are having ownership problems.  With your situation, I think you may be trapped with a double login situation.  With the password protected shares you need one login and a separate group setup to allow access to only that section of the file system.  Then you will need a 'no login' required access to the remainder of the file system (the part with nobody:users setup).  This will prevent writing to the nobody:users portion and having a user become the owner of a resource in that portion of the file system.  Unfortunately, you may find that the logged-in user may still be able to access the unprotected side...

[dgaschk]

All unRAID users are in the group "users". A second group is not required. unRAID does not use Linux permissions to restrict file access. However, incorrect Linux file permissions can prevent otherwise permitted access. As you mentioned, "The Linux permissions are used by Samba and new files generated through Samba will set any Linux permission setup that the System Administrator wants." All unRAID files are given the same permissions by design. In this case, Lime-tech is the System Administrator and file access restriction is handled at the share level by SAMBA.

 

All files must have group ownership set to "users". All files need to have rw permission in the group field. The owner field and permissions are not used to restrict or permit file access. Since all users are in the "users" group, everyone has access to all files at the Linux file system level. SAMBA is used to restrict access to entire shares.

 

For these reasons, root is able to login to a terminal session but is not allowed to connect to a file shares. Users are able to connect to file shares but are not allowed to connect with a terminal session.

 

Hello,

 

*Note: The reason I have a separate user account in this case is there are password-protected shares that only certain users can connect to.

 

Where I am confused at the moment is where you are having ownership problems.  With your situation, I think you may be trapped with a double login situation.  With the password protected shares you need one login and a separate group setup to allow access to only that section of the file system.  Then you will need a 'no login' required access to the remainder of the file system (the part with nobody:users setup).  This will prevent writing to the nobody:users portion and having a user become the owner of a resource in that portion of the file system.  Unfortunately, you may find that the logged-in user may still be able to access the unprotected side...

[Frank1940]

All unRAID users are in the group "users". A second group is not required. unRAID does not use Linux permissions to restrict file access. However, incorrect Linux file permissions can prevent otherwise permitted access. As you mentioned, "The Linux permissions are used by Samba and new files generated through Samba will set any Linux permission setup that the System Administrator wants." All unRAID files are given the same permissions by design. In this case, Lime-tech is the System Administrator and file access restriction is handled at the share level by SAMBA.

 

All files must have group ownership set to "users". All files need to have rw permission in the group field. The owner field and permissions are not used to restrict or permit file access. Since all users are in the "users" group, everyone has access to all files at the Linux file system level. SAMBA is used to restrict access to entire shares.

 

For these reasons, root is able to login to a terminal session but is not allowed to connect to a file shares. Users are able to connect to file shares but are not allowed to connect with a terminal session.

 

Suggest you look at:

 

 

/etc/samba/smb.conf

 

Where these lines of code are included:

 

     

      # hook for user-defined samba config
        include = /boot/config/smb-extra.conf

 

Then look at both

 

  /etc/samba/smb-shares.conf

          and

  /etc/samba/smb.conf-sample

 

The smb.conf-sample contains several examples of ways that users can set up shares with users and various levels of access.  Obviously (and as I have said) , this is not territory for the novice who is not prepared to devote a lot of time to study and learn how things really work.

       

 

PS-- you can look at these files with the cat command:

 

cat smb.conf

 

 

 

 

[dgaschk]

The OP is not attempting anything that requires custom SMB configuration. The issue is that guest users cannot modify files created by user-A even though the share is configured for guest read-write access. A share configured for guest read-write access should allow any user to modify any file in the share regardless of who created the file. This indicates that the group permissions are not correct and can be remedied using newperms.

 

In order to determine why this is happening we need to know how the files are being created.

 

 

[Gizmotoy]

The OP is not attempting anything that requires custom SMB configuration. The issue is that guest users cannot modify files created by user-A even though the share is configured for guest read-write access. A share configured for guest read-write access should allow any user to modify any file in the share regardless of who created the file. This indicates that the group permissions are not correct and can be remedied using newperms.

 

In order to determine why this is happening we need to know how the files are being created.

 

Yes, you understand the problem exactly.  This seems like a simple thing that may be a bug or something setup-related.  This is basic unRaid functionality that I shouldn't even need to dig into Linux for, let alone go around manually modifying Samba.

 

It appears that permissions for user/group/other are all identical between files guests can modify and those they can't.  After running "ls -l", the only perceivable difference is the owner.  The all three sets of permissions and the group are all the same.  However, files with their owner set to <username> cannot be modified by guest users.  Obviously, this does not make a whole lot of sense.  I'm sure I confused things by essentially using ownership and permissions interchangeably in my first post, which I apologize for.  If the files and directories are all owned by a user in the group "users", and the group permissions are set correctly, this should work.

 

I definitely don't understand Frank's position that I need to create users with full root access to the box in order to share files in this manner.  This is explicitly the reason why groups exist in Linux, and I doubt the intention of unRaid's user management tool is for it to create files that are partially accessible to other users.  As dgaschk alluded to, if the group permissions are set properly, and the users are in the same group, it *should* work.  The problem is that it isn't working.

 

I described the file creation process in the first post, but again with more (accurate) detail:

I log into the share over SMB as <username>.  I create a file or directory.  I log into the share over SMB from another machine as a guest.  The file or directory I just created cannot be modified or renamed by the guest user.  If I telnet into the unRaid server, I can see that the permissions on the new directory are identical to directories I can modify.  The group is also the same (users).  The only difference is the owner.  The directories I can modify as guest are owned by "nobody", and those I can't are owned by <username>.

 

The share security settings for this share are "Yes" and "Public".

 

I'm starting to think Samba may be hosed.  I've had the array started and stopped quite a bit preclearing and swapping out drives over the past week.  Maybe it's time for a reboot.  I'll try newperms first, though.

[Frank1940]

Hello,

 

*Note: The reason I have a separate user account in this case is there are password-protected shares that only certain users can connect to.

 

Where I am confused at the moment is where you are having ownership problems.  With your situation, I think you may be trapped with a double login situation.  With the password protected shares you need one login and a separate group setup to allow access to only that section of the file system.  Then you will need a 'no login' required access to the remainder of the file system (the part with nobody:users setup).  This will prevent writing to the nobody:users portion and having a user become the owner of a resource in that portion of the file system.  Unfortunately, you may find that the logged-in user may still be able to access the unprotected side...

 

I am the one confused?  IF Gizmotoy truly wants a share where only CERTAIN USERS can connect to, he can not have a guest account for that share. 

 

Unfortunately, Samba is a very complicated system because it attempting to blend a file system which has virtually no protection (Windows peer-to-peer sharing) and one which does (UNIX/Linux).  It works the way it works (unRAID has a specific setup defined in its smb.conf files)  and if it is not working the way the particular user requires (or thinks) it should, then that user has to learn the in's-and-outs of the system to beat it into submission.  Google 'Samba manual' and you will have the bible.

 

I am out of here..

[Gizmotoy]

Hello,

 

*Note: The reason I have a separate user account in this case is there are password-protected shares that only certain users can connect to.

 

Where I am confused at the moment is where you are having ownership problems.  With your situation, I think you may be trapped with a double login situation.  With the password protected shares you need one login and a separate group setup to allow access to only that section of the file system.  Then you will need a 'no login' required access to the remainder of the file system (the part with nobody:users setup).  This will prevent writing to the nobody:users portion and having a user become the owner of a resource in that portion of the file system.  Unfortunately, you may find that the logged-in user may still be able to access the unprotected side...

 

I am the one confused?  IF Gizmotoy truly wants a share where only CERTAIN USERS can connect to, he can not have a guest account for that share. 

 

Yes, I believe so.  I never said I wanted my protected share to be accesible by the guest account.  That would defeat the purpose of a protected share.  The issue I'm having is between named and guest users on public shares.

[Gizmotoy]

Ok.  I did some testing.

 

I create a directory using the named account.  Here is the result:

drwxrws--- 1 jason  users  48 2012-11-18 09:27 Xtesting/

 

I now go to a machine that's logged in as a guest to that public share.  I'm unable to rename or delete that directory.

 

I telnet into the server and run "newperms Xtesting/", basically running dgaschk's suggestion only on the directory in question.  The new listing is shown as:

processing Xtesting/
... chmod -R go-rwx,u-x,g+u,ug+X Xtesting/
... chown -R nobody:users Xtesting/

drwxrws--- 1 nobody users  48 2012-11-18 09:27 Xtesting/

 

Note that literally the only thing to change was the owner, from jason to nobody.  The permissions and group remain the same.  I now go back to the machine that's logged in as a guest to that share.  I am now able to rename or delete the directory as a guest.

 

This seems very unusual.

[dgaschk]

The SGIU bit is set. This is incorrect. File permissions should be -rw-rw--- (660) . Directories: drwxrwx--- (770). How is the SGID bit being set? The newperms script does correct this because it is not supposed to happen and was not anticipated.

[Gizmotoy]

The SGIU bit is set. This is incorrect. File permissions should be -rw-rw--- (660) . Directories: drwxrwx--- (770). How is the SGID bit being set? The newperms script does correct this because it is not supposed to happen and was not anticipated.

 

Interesting.  Then let me run newperms on the entire share (it's huge, nearly 16TB, so I didn't want to start with that) and I'll report back.

 

So I ran newperms on the user share ("newperms /mnt/user/Movies/", in this case).  It finished successfully.  All of the directories are now drwxrwx--- and the files are -rw-rw---.  So, from a machine logged into my named account, I created a new directory.  The result is:

drwxrws--- 1 jason  users  48 2012-11-18 17:36 Xtesting/

The SGID bit is set.

 

I removed the SGID (chmod g-s) from the share, and created a new directory using the named user, which now looks like:

drwxrwx--- 1 jason  users  48 2012-11-18 17:47 Ztesting/

 

I switched to the machine logged in as a guest.  I attempted to rename the directory, and was denied.

 

So the SGID bit is gone, but it didn't affect the behavior at all.

[dgaschk]

The SGIU bit is set. This is incorrect. File permissions should be -rw-rw--- (660) . Directories: drwxrwx--- (770). How is the SGID bit being set? The newperms script does correct this because it is not supposed to happen and was not anticipated.

 

Interesting.  Then let me run newperms on the entire share (it's huge, nearly 16TB, so I didn't want to start with that) and I'll report back.

 

I made a typo. The  newperms script will NOT fix this as demonstrated by your post showing:

drwxrws--- 1 nobody users  48 2012-11-18 09:27 Xtesting/

[Gizmotoy]

The SGIU bit is set. This is incorrect. File permissions should be -rw-rw--- (660) . Directories: drwxrwx--- (770). How is the SGID bit being set? The newperms script does correct this because it is not supposed to happen and was not anticipated.

 

Interesting.  Then let me run newperms on the entire share (it's huge, nearly 16TB, so I didn't want to start with that) and I'll report back.

 

I made a typo. The  newperms script will NOT fix this as demonstrated by your post showing:

drwxrws--- 1 nobody users  48 2012-11-18 09:27 Xtesting/

 

No, but I was able to fix it manually easily enough (see edits above).  Unfortunately it still didn't resolve the issue.

[dgaschk]

What are the permissions of the enclosing directory?

[Gizmotoy]

What are the permissions of the enclosing directory?

It's

drwxrwx--- 1 nobody users  136 2012-11-18 19:40 Movies/

[dgaschk]

Try restarting both unRAID and Windows.