- why the NAS implementation does'nt respect the Samba protocol: user access rights should always take precedense on group rights ?
Samba is an open-source implementation of the SMB protocol. But this has nothing to do with the SMB protocol. The GUI Network Access tab configures simple share access lists, which are enforced by Samba -- not user and group rights.
Reset file permissions: it will reset the permissions configuration defaults and apply them instead of applying the permissions as they are configured
It means, we need to reconfigure user access rights from scratch. As I understand it, after a reset, I am again going to change the user rights to what I want them. So, I am back to starting point: the existing files will keep the access rights done by reset and not the new rights I am giving to the users
If I follow this logic, the only way to get proper rights is:
- format NAS
- setup groups and users
- populate the NAS with files
- never change permissions for an existing user after that otherwise existing files will keep previous access rights of the user
What should be needed is:
- redesign the GUI so that it is clear we cannot setup a user differently than its group: still, it is a really restricted way to setup groups and users, but at least we have no more confusion (ro user of a rw group)
- provide a way to properly apply the configured users permissions to all existing files, or do it automatically when we change permissions for an existing user
- provide a way in GUI to add exceptions to users in a given group
I hope you can enlighten me if I am still getting things wrong
Reset file permissions: it will reset the permissions configuration defaults and apply them instead of applying the permissions as they are configured
It means, we need to reconfigure user access rights from scratch. As I understand it, after a reset, I am again going to change the user rights to what I want them. So, I am back to starting point: the existing files will keep the access rights done by reset and not the new rights I am giving to the users
Oh, you're absolutely right. I thought that option was added some time ago, but looking now I see that it never was. So, currently, the only good way for you to recursively reset permissions is to do it from Windows.
1) Log in to the NAS as admin
2) Right-click on the Share, and go to Properties
3) Switch to the Security tab
4) Make sure the permissions are configured how you want them to be on all the share contents
5) Click the Advanced button near the bottom of the windows.
6) Click the box next to "Replace all child object permission entries ..."
- redesign the GUI so that it is clear we cannot setup a user differently than its group: still, it is a really restricted way to setup groups and users, but at least we have no more confusion (ro user of a rw group)
That's not exactly true. You can set up a user differently from his groups, as long the user-specific exception is to allow write access. So, if his group is read-only, but the user allows write access, then it will work.
- provide a way in GUI to add exceptions to users in a given group
Samba simply doesn't support read-only user exceptions from the share access side of things. That's probably because it's unusual to say "everybody in jack's group gets read/write access to the share, except jack". It's much more common to say "everybody in jack's group get read-only access to the share, and only jack can write to the share". However, one way to effectively do that would be to just add a new group, with your desired read-only user removed from that new group.
Your last 2 posts do resume and answer all questions
I just hope there will be an update to make all through GUI (Apply recursively user permissions, remove option to set a ro only user in a rw group...)
I still wonder about one option:
- in "File Access" Security tab: we can actually setup Folder Owner and Folder Group differently from the corresponding user and group. Which config will take precedense in that case?
exp:
Folder Owner (new_user😞 rw
Folder Group (new_group😞 rw
new_group: ro
new_user: ro
I know it is no sense as we "should" set same permissions for Folder Owner and new_user; and respectively for new_group and Folder Group, however the GUI does offer thiese 2 contradictory choices. Which one will have precedense ? And maybe it is a good idea to remove this redundancy from GUI
I just hope there will be an update to make all through GUI (Apply recursively user permissions, remove option to set a ro only user in a rw group...)
@I posted this in the idea exchange, so people who want these features can vote for them. @chopin70 you might want to check the links and click on the up arrow.
I just hope there will be an update to make all through GUI (Apply recursively user permissions, remove option to set a ro only user in a rw group...)
We may be able to make things behave more naturally, regarding the RO user in an RW group issue. We've proposed a change to the Samba team (here) that would allow an individual user setting to have priority over a group setting, so we'll see what sort of feedback we get.
I still wonder about one option:
- in "File Access" Security tab: we can actually setup Folder Owner and Folder Group differently from the corresponding user and group. Which config will take precedense in that case?
These are analagous to the built-in CREATOR OWNER and CREATOR GROUP Windows ACEs, which get used for permission inheritance. On Linux/UNIX, they must always exist, and should be configurable.
Thanks a lot for all your detailed feedback and information so far!
About the way I setup groups: I will take the habit of creating ro and rw groups for every share, and add users to different groups until things get modified at the GUI and eventually SAMBA level
I tested the 6.5.2-T500 Beta 2 firmware since I saw in change history this entry
[Beta 2] Changed SMB share access control to give rights assigned to individual users higher priority than group rights.
Created:
- share: "new_share"
- group: "new_group" with r/w access to the "new_share"
- user: "new_user" member of "new_group
Test scenarios:
1- new_user: nothing checked for r/w will give it same credentials as his group: r/w in this case
2- new_user: r/o access to new_share will actually give it the proper exeption, that is r/o
Also, I noticed that the credentials are now applied to root fies, folders and subfolders when they are changed in the GUI. The old credentials are immeadiately replaced on every file in the share
Things seem now more consistent without contradictions. Admin is also always forced to be r/w in GUI
To be improved:
One last thing remain: adding an extra box mentioning either "no access"
- If "no access" is chosen: no read or write permissions will be given to the user or group
- If nothing selected, user willl inherit from group as expected
Home someone else can confirm the good news implemented in Beta 2
I wish I had seen this earlier. I disagree that the implementation of user right always overriding group rights is the "correct" one, at least in the examples given. "RO" is a granting of permission to read and no permission to write given or taken, which is different from an explicit deny for write, but you want it treated that way. Having explicit allow and deny to read and write independently is the only way you can please everybody.
I noticed that the windows option : "apply these permissions to objects and/or containers within this container only" is not affected when changing permissions in GUI
I had it ticked by default on some shares. That's what caused new files/subfolders no inheriting proper permissions from the share
The key here is the word "only", which won't apply defined permissions to child objects created
Applying permissions in GUI won't propagate to child objects if this option is ticked. I won't aware about the "only" part of that sentence.
You're describing "R", not "RO". Ready-only ("RO") is indeed an explicit write denial in every computing context that I'm familiar with.
The ambiguity of it is why neither Linux nor NTFS use it and why Netgear probably shouldn't either. Since a ReadyNAS has multiple access methods, how does the granting of "RO" attributes via Samba affect a user that is accessing via another protocol? If they don't behave in the same way (and since Linux doesn't assign individual user rights for files except for the owner, I don''t think they will), then there may be an illusion of protection that is not really there (unless Samba is the only enabled protocol). Apparently NFS does use the term "Read Only". How does it behave under these conditions?
