NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
chopin70
Jun 29, 2016Virtuoso
User and group broken permissions
Hi,
I am using latest OS 6.5.1
I setup a share called "torrents"
I have two groups: users and famille
famille group has one user: enfants
In SMB Network access: users: r/w - famille: no access - enfants: no access
In file access: same setup
However, the user "enfants" still has r/w access on the torrents share
Even if I set them to read only, still they have r/w access
This use to work before on early 6.4.x versions, last time I checked
I tried to reset permissions, but no fix
As soon as the group users has ro permission, "enfants" gets r/o access, despite it is not a membrer of that group
63 Replies
Replies have been turned off for this discussion
- chopin70Virtuoso
Firther investigation shows that members of group "famille", always get permissions from the group users, overriding their own permissions
It is like setting up user exceptions has no effect/use
- JennCNETGEAR Employee Retired
Hello chopin70,
Can you try creating a new folder/share and configure its permissions the same way you did on the Torrents share? Then. check if the permissions work.
Please also verify under Overview if it does show the version 6.5.1.
Regards,
- chopin70Virtuoso
In overview, it well shows 6.5.1
I started again from scratch, removed my users and groups, reset permissions on the share "torrents".
Created the group family and the member "enfants" in it. The member still only inherits permissions from the group "users".
Basically, the member can escalate permissions from the group "users", but cannot get lower permission than the "users" group, despite it is not member of that group
I will create a new share and start on it from scratch
- omicron_persei8LuminaryCan you try not to use the group "users"? Don't apply any permission to it.
Just r/o to "famille".
If necessary, create a separate group containing the users that aren't in "famille" and for which your want r/w. - chopin70Virtuoso
I created a new share called "Test"
I setup access as below in picture
ja: is member a users group
mari: member of family group
enfants: member of family group
With the below setup, enfants and mari have r/w access despite they should normally have no access at all.
If now I give the group users no access at all (I uncheck both ro and rw options), enfants will have no access at all to the share
If now I give the group users no access at all but escalate the user enfants to read only, it will correctly have a read only access
However, keep in mind, the 2 users are not members of the family group
Edit: I also tried to modify the family group permissions, they don't impact its members permissions
Again, any member, what ever is its group, it seems like it will always inherit users group permissions if they are higher than the permissions attributed to the member. The member can still escalate its own permissions above the users group permissions if we configure it to do so.
This is really a serious security issue as it doesn't behave at all as expected!
- omicron_persei8LuminaryI don't reproduce this on my nas.
Users/groups get correct permissions.
Just in case, when you look at the user, you see the primary group, not all the groups. When you look at the groups, you see all users. Are you sure that your users are not in both groups?
I have created testgroup, testuser (users, testgroup), testuser2. I have created a testshare with r/w to users, r/o to testgroup.
Testuser gets r/w as expected.
Testuser2 gets r/o as expected. - omicron_persei8Luminary*testusers2 (testgroup)
- chopin70Virtuoso
I have no secondary members in the group users, opening th egroup correclty shows that no other members are included in it
I will try with a new group and new user that weren't created before in the NAS history
- chopin70Virtuoso
I created test_group and a member of it called test_user
I gave r/w to users and r/w to test_group and no access at all to test_user
test_user still has a read only access for files that were already in the share and r/w access for new files created
I rebooted the NAS but it doesn't fix the issue. Only way is to remove the permissions from the group users
Please help.
Only current fix for now is to not set the users group rights at all. However, "Folder Group" must be set to r/w to be able for me to configure the members access
Really wired
- chopin70Virtuoso
After both PC and NAS turned off during the night, I tried the following:
- removed credentials from windows, logoff and login to reset shares access permissions
- created a new test_user member of the group family as below
- the actual groups{members}: users{ja} - family{test_user, enfants, ma}
- created a share "test_share"
- test_share: user_owner: ja (r/w) - group_owner: users (r/w)
- test_share groups and users permissions: ja:r/w - admin:r/w - users:r/w - guest:0 - family:0 - test_user:0, enfants:0, ma:0
0 means no read access, that is cannot mount
Now, both under Windows and Android acces: all members of the family group has r/w permissions despite they should not even be able to mount as per their permissions
If I remove all permissions (no mount) from the group users, I can setup proper permissions for all members of the family group
If I revoke group_owner permissions, users of the group family loose their access whatever I select for them
There are also near similar reports in the forum, one of them here:
Here's the content of the samba.conf for share2: it sounds no issues in the file and no members of the family group are included
[share2] path = /data/share2 comment = "" admin users = "+admin","Administrator" write list = "ja","@users","+admin","Administrator" valid users = "ja","@users","+admin","Administrator" follow symlinks = 1
Please, some moderator/technician provide help to fix these permissions issues
- chopin70Virtuoso
In complement to the detailed last post:
when I run in SSH this command:
root@RNDU2000-1:~# id -a enfants
uid=102(enfants) gid=101(family) groups=101(family)root@RNDU2000-1:~# id -a ma
uid=101(ma) gid=101(family) groups=101(family)which sounds right. They ar eclearly not parts of the group users
So the issue is in relation to a bug at kernel/os level
- omicron_persei8LuminaryI have created:
user_users member of users
user_both_groups member of users, test_group
user_test_group member of test_group
test_share: users r/w, everything else at no
I can write to test_share from user user_test_group, which is not normal.
Local users & groups are ok.
Interestingly, if I run pdbedit -L -v, I see all three users with the same primary group SID. But I don't know how to read the output of that command.- chopin70Virtuoso
Many thanks for your confirmation
This confirms that something is going very nasty at permissions level with the new upadates. The group users is taking over every user permissions. Groups became meaningless too as the group users is imposing all permissions. Currently, the only fix is to deny groups any permission and setup separately the users.
This puts the light on a complex and non sense users/groups permissions setup:
- what is the meaning of being able to setup separately the permissions of owner_user + the corresponding user and owner_group + corresponding group ? Which one will have the priority if we setup owner_user and the corresponding user differently ?
- what is the point of setting up group permissions if users of the actual group will have by default no read and no write access ?
To make things meaningful and obvious, we need the following:
- remove the unclear and redundant way allowing to set up two different access permissions for the same members/groups as in point 1
- in addition to the ro and rw options, add an option "inherit group permissions". That way, it is clear that:
- nothing is checked gives no mount access
- ro or rw if we need exceptions for the user. Else, "inherit group permissions" set by default for new users of a given group
- if we modify an existing group permissions, ask if we want to modify permissions for all its existing members or not (across all shares)
- if we modify the group for a given a user, ask if the user permissions should be changed to inherit the new group permissions, for all the shares
Actual situation is a total confusion. Not surprising that it ends to teh current inacceptable situation.
I really appreciate the great work done with the support team for ReadyNAS. They gave us uptodate options on legacy years-old hardware.
However, messing up a linux build to the level of breaking its basics, users and groups permissions, is something rather unbelievable...
Hope this will be fixed asap and my suggestions to make things more linux structured considered rapidly
- omicron_persei8LuminaryI'm doing more testing. I presume something is wrong with samba.
I'll update the thread when done.- chopin70Virtuoso
I edit my post above yours: it resumes the real issues in the actual GUI and how they should be fixed
The current way to setup permissions seems a complete mess if we look at it closer. It should be ways more clear and without contradictions
- omicron_persei8Luminary
RN312 running F/W 6.5.1
I would expect that a user with a more specifc permission set would overrule the inherited permission from the group, but maybe I'm wrong about this.
Nevertheless, with all testing below, I confirm that in some situations, permissions are not working properly.
The permissions set on group "users" overrule the other permissions (even though a user can be removed from the group "users").
In some situations, users don't inherit permissions from the group at all.
See all testing below... Please let me know if any typo (it's a long text, so it can happen) or any suggestion on tuning the test.
Test users and groups:user_users_no: primary group is users, no secondary group, no permission specified on the share user_users_ro: primary group is users, no secondary group, read/only permission specified on the share user_users_rw: primary group is users, no secondary group, read/write permission specified on the share user_users_groupno_no: primary group is users, secondary group is groupno, no permission specified on the share user_users_groupno_ro: primary group is users, secondary group is groupno, read/only permission specified on the share user_users_groupno_rw: primary group is users, secondary group is groupno, read/write permission specified on the share user_groupno_no: primary group is groupno, no secondary group, no permission specified on the share user_groupno_ro: primary group is groupno, no secondary group, read/only permission specified on the share user_groupno_rw: primary group is groupno, no secondary group, read/write permission specified on the share user_users_groupro_no: primary group is users, secondary group is groupro, no permission specified on the share user_users_groupro_ro: primary group is users, secondary group is groupro, read/only permission specified on the share user_users_groupro_rw: primary group is users, secondary group is groupro, read/write permission specified on the share user_groupro_no: primary group is groupro, no secondary group, no permission specified on the share user_groupro_ro: primary group is groupro, no secondary group, read/only permission specified on the share user_groupro_rw: primary group is groupro, no secondary group, read/write permission specified on the share user_users_grouprw_no: primary group is users, secondary group is grouprw, no permission specified on the share user_users_grouprw_ro: primary group is users, secondary group is grouprw, read/only permission specified on the share user_users_grouprw_rw: primary group is users, secondary group is grouprw, read/write permission specified on the share user_grouprw_no: primary group is grouprw, no secondary group, no permission specified on the share user_grouprw_ro: primary group is grouprw, no secondary group, read/only permission specified on the share user_grouprw_rw: primary group is grouprw, no secondary group, read/write permission specified on the share
/etc/password:user_users_no:x:114:100::/home/user_users_no:/bin/false
user_users_ro:x:115:100::/home/user_users_ro:/bin/false
user_users_rw:x:116:100::/home/user_users_rw:/bin/false
user_users_groupno_no:x:117:100::/home/user_users_groupno_no:/bin/false
user_users_groupno_ro:x:118:100::/home/user_users_groupno_ro:/bin/false
user_users_groupno_rw:x:119:100::/home/user_users_groupno_rw:/bin/false
user_groupno_ro:x:120:102::/home/user_groupno_ro:/bin/false
user_groupno_no:x:121:102::/home/user_groupno_no:/bin/false
user_groupno_rw:x:122:102::/home/user_groupno_rw:/bin/false
user_users_groupro_no:x:123:100::/home/user_users_groupro_no:/bin/false
user_users_groupro_ro:x:124:100::/home/user_users_groupro_ro:/bin/false
user_users_groupro_rw:x:125:100::/home/user_users_groupro_rw:/bin/false
user_groupro_no:x:126:103::/home/user_groupro_no:/bin/false
user_groupro_ro:x:127:103::/home/user_groupro_ro:/bin/false
user_groupro_rw:x:128:103::/home/user_groupro_rw:/bin/false
user_users_grouprw_no:x:129:100::/home/user_users_grouprw_no:/bin/false
user_users_grouprw_ro:x:130:100::/home/user_users_grouprw_ro:/bin/false
user_users_grouprw_rw:x:131:100::/home/user_users_grouprw_rw:/bin/false
user_grouprw_no:x:132:105::/home/user_grouprw_no:/bin/false
user_grouprw_ro:x:133:105::/home/user_grouprw_ro:/bin/false
user_grouprw_rw:x:134:105::/home/user_grouprw_rw:/bin/false
/etc/group:users:x:100:
groupno:x:102:user_users_groupno_no,user_users_groupno_ro,user_users_groupno_rw
groupro:x:103:user_users_groupro_no,user_users_groupro_ro,user_users_groupro_rw
grouprw:x:105:user_users_grouprw_no,user_users_grouprw_ro,user_users_grouprw_rw
Configured share permissions (excluding group "users"):(no) means that no checkbox is ticked
(user): (permission set on share)
Everyone: (no)
users: (defined in different situations below)
user_users_no: (no)
user_users_ro: read/only
user_users_rw: read/write
user_users_groupno_no: (no)
user_users_groupno_ro: read/only
user_users_groupno_rw: read/write
user_groupno_no: (no)
user_groupno_ro: read/only
user_groupno_rw: read/write
user_users_groupro_no: (no)
user_users_groupro_ro: read/only
user_users_groupro_rw: read/write
user_groupro_no: (no)
user_groupro_ro: read/only
user_groupro_rw: read/write
user_users_grouprw_no: (no)
user_users_grouprw_ro: read/only
user_users_grouprw_rw: read/write
user_grouprw_no: (no)
user_grouprw_ro: read/only
user_grouprw_rw: read/write
Test Script (on separate Linux machine):#!/bin/bash
for a_user in \
user_noexist \
user_users_no user_users_ro user_users_rw \
user_users_groupno_no user_users_groupno_ro user_users_groupno_rw \
user_groupno_no user_groupno_ro user_groupno_rw \
user_users_groupro_no user_users_groupro_ro user_users_groupro_rw \
user_groupro_no user_groupro_ro user_groupro_rw \
user_users_grouprw_no user_users_grouprw_ro user_users_grouprw_rw \
user_grouprw_no user_grouprw_ro user_grouprw_rw \
; do
echo -n "User: ${a_user} -> "
echo -n "Mount: "
if (mount //testnas/share /mnt -o user=${a_user},password=password &> /dev/null); then
echo -n "yes"
echo -n ", Read: "
if (ls /mnt &> /dev/null); then
echo -n "yes"
else
echo -n "no"
fi
echo -n ", Write: "
if (touch /mnt/file.empty 2> /dev/null); then
echo -n "yes"
else
echo -n "no"
fi
umount /mnt &> /dev/null
else
echo -n "no"
fi
echo ""
sleep 1
done
---------------------------
Situation 1) group "users" has read/write
Samba permission on the test share:[share]
path = /data/share
comment = ""
admin users = "+admin","Administrator"
read list = "user_groupno_ro","user_groupro_ro","user_grouprw_ro","user_users_groupno_ro","user_users_groupro_ro","user_users_grouprw_ro","user_users_ro","@groupro"
write list = "user_groupno_rw","user_groupro_rw","user_grouprw_rw","user_users_groupno_rw","user_users_groupro_rw","user_users_grouprw_rw","user_users_rw","@grouprw","@users","+admin","Administrator"
valid users = "user_groupno_ro","user_groupno_rw","user_groupro_ro","user_groupro_rw","user_grouprw_ro","user_grouprw_rw","user_users_groupno_ro","user_users_groupno_rw","user_users_groupro_ro","user_users_groupro_rw","user_users_grouprw_ro","user_users_grouprw_rw","user_users_ro","user_users_rw","@groupro","@grouprw","@users","+admin","Administrator"
Script output:User: user_noexist -> Mount: no
User: user_users_no -> Mount: yes, Read: yes, Write: yes
User: user_users_ro -> Mount: yes, Read: yes, Write: yes
User: user_users_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_groupno_no -> Mount: yes, Read: yes, Write: yes
User: user_users_groupno_ro -> Mount: yes, Read: yes, Write: yes
User: user_users_groupno_rw -> Mount: yes, Read: yes, Write: yes
User: user_groupno_no -> Mount: yes, Read: yes, Write: yes
User: user_groupno_ro -> Mount: yes, Read: yes, Write: yes
User: user_groupno_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_groupro_no -> Mount: yes, Read: yes, Write: yes
User: user_users_groupro_ro -> Mount: yes, Read: yes, Write: yes
User: user_users_groupro_rw -> Mount: yes, Read: yes, Write: yes
User: user_groupro_no -> Mount: yes, Read: yes, Write: yes
User: user_groupro_ro -> Mount: yes, Read: yes, Write: yes
User: user_groupro_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_no -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_ro -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_rw -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_no -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_ro -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_rw -> Mount: yes, Read: yes, Write: yes
Configured vs effective share permissions (based on above results):(user): (permission set on share) -> (actual result) [expectation if different]
Everyone: (no) -> no access
users: read/write -> n/a
user_users_no: (no) -> read/write
user_users_ro: read/only -> read/write [expected read/only]
user_users_rw: read/write -> read/write
user_users_groupno_no: (no) -> read/write
user_users_groupno_ro: read/only -> read/write [expected read/only]
user_users_groupno_rw: read/write -> read/write
user_groupno_no: (no) -> read/write [expected no access]
user_groupno_ro: read/only -> read/write [expected read/only]
user_groupno_rw: read/write -> read/write
user_users_groupro_no: (no) -> read/write
user_users_groupro_ro: read/only -> read/write [expected read/only]
user_users_groupro_rw: read/write -> read/write
user_groupro_no: (no) -> read/write [expected read/only]
user_groupro_ro: read/only -> read/write [expected read/only]
user_groupro_rw: read/write -> read/write
user_users_grouprw_no: (no) -> read/write
user_users_grouprw_ro: read/only -> read/write [expected read/only]
user_users_grouprw_rw: read/write -> read/write
user_grouprw_no: (no) -> read/write
user_grouprw_ro: read/only -> read/write [expected read/only]
user_grouprw_rw: read/write -> read/write
---------------------------
Situation 2) group "users" has read/only
Samba permission on the test share:[share]
path = /data/share
comment = ""
admin users = "+admin","Administrator"
read list = "user_groupno_ro","user_groupro_ro","user_grouprw_ro","user_users_groupno_ro","user_users_groupro_ro","user_users_grouprw_ro","user_users_ro","@groupro","@users"
write list = "user_groupno_rw","user_groupro_rw","user_grouprw_rw","user_users_groupno_rw","user_users_groupro_rw","user_users_grouprw_rw","user_users_rw","@grouprw","+admin","Administrator"
valid users = "user_groupno_ro","user_groupno_rw","user_groupro_ro","user_groupro_rw","user_grouprw_ro","user_grouprw_rw","user_users_groupno_ro","user_users_groupno_rw","user_users_groupro_ro","user_users_groupro_rw","user_users_grouprw_ro","user_users_grouprw_rw","user_users_ro","user_users_rw","@groupro","@grouprw","@users","+admin","Administrator"
Script output:User: user_noexist -> Mount: no
User: user_users_no -> Mount: yes, Read: yes, Write: no
User: user_users_ro -> Mount: yes, Read: yes, Write: no
User: user_users_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_groupno_no -> Mount: yes, Read: yes, Write: no
User: user_users_groupno_ro -> Mount: yes, Read: yes, Write: no
User: user_users_groupno_rw -> Mount: yes, Read: yes, Write: yes
User: user_groupno_no -> Mount: yes, Read: yes, Write: no
User: user_groupno_ro -> Mount: yes, Read: yes, Write: no
User: user_groupno_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_groupro_no -> Mount: yes, Read: yes, Write: no
User: user_users_groupro_ro -> Mount: yes, Read: yes, Write: no
User: user_users_groupro_rw -> Mount: yes, Read: yes, Write: yes
User: user_groupro_no -> Mount: yes, Read: yes, Write: no
User: user_groupro_ro -> Mount: yes, Read: yes, Write: no
User: user_groupro_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_no -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_ro -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_rw -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_no -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_ro -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_rw -> Mount: yes, Read: yes, Write: yes
Configured vs effective share permissions (based on above results):(user): (permission set on share) -> (actual result) [expectation if different]
Everyone: (no) -> no access
users: read/write -> n/a
user_users_no: (no) -> read/only
user_users_ro: read/only -> read/only
user_users_rw: read/write -> read/write
user_users_groupno_no: (no) -> read/only
user_users_groupno_ro: read/only -> read/only
user_users_groupno_rw: read/write -> read/write
user_groupno_no: (no) -> read/only [expected no access]
user_groupno_ro: read/only -> read/only
user_groupno_rw: read/write -> read/write
user_users_groupro_no: (no) -> read/only
user_users_groupro_ro: read/only -> read/only
user_users_groupro_rw: read/write -> read/write
user_groupro_no: (no) -> read/only
user_groupro_ro: read/only -> read/only
user_groupro_rw: read/write -> read/write
user_users_grouprw_no: (no) -> read/write
user_users_grouprw_ro: read/only -> read/write [expected read/only]
user_users_grouprw_rw: read/write -> read/write
user_grouprw_no: (no) -> read/write
user_grouprw_ro: read/only -> read/write [expected read/only]
user_grouprw_rw: read/write -> read/write
---------------------------
Situation 3) group "users" has (no) specified permissions
Samba permission on the test share:[share]
path = /data/share
comment = ""
admin users = "+admin","Administrator"
read list = "user_groupno_ro","user_groupro_ro","user_grouprw_ro","user_users_groupno_ro","user_users_groupro_ro","user_users_grouprw_ro","user_users_ro","@groupro"
write list = "user_groupno_rw","user_groupro_rw","user_grouprw_rw","user_users_groupno_rw","user_users_groupro_rw","user_users_grouprw_rw","user_users_rw","@grouprw","+admin","Administrator"
valid users = "user_groupno_ro","user_groupno_rw","user_groupro_ro","user_groupro_rw","user_grouprw_ro","user_grouprw_rw","user_users_groupno_ro","user_users_groupno_rw","user_users_groupro_ro","user_users_groupro_rw","user_users_grouprw_ro","user_users_grouprw_rw","user_users_ro","user_users_rw","@groupro","@grouprw","+admin","Administrator"
Script output:User: user_noexist -> Mount: no
User: user_users_no -> Mount: no
User: user_users_ro -> Mount: yes, Read: yes, Write: no
User: user_users_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_groupno_no -> Mount: no
User: user_users_groupno_ro -> Mount: yes, Read: yes, Write: no
User: user_users_groupno_rw -> Mount: yes, Read: yes, Write: yes
User: user_groupno_no -> Mount: no
User: user_groupno_ro -> Mount: yes, Read: yes, Write: no
User: user_groupno_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_groupro_no -> Mount: no
User: user_users_groupro_ro -> Mount: yes, Read: yes, Write: no
User: user_users_groupro_rw -> Mount: yes, Read: yes, Write: yes
User: user_groupro_no -> Mount: no
User: user_groupro_ro -> Mount: yes, Read: yes, Write: no
User: user_groupro_rw -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_no -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_ro -> Mount: yes, Read: yes, Write: yes
User: user_users_grouprw_rw -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_no -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_ro -> Mount: yes, Read: yes, Write: yes
User: user_grouprw_rw -> Mount: yes, Read: yes, Write: yes
Configured vs effective share permissions (based on above results):(user): (permission set on share) -> (actual result) [expectation if different]
Everyone: (no) -> no access
users: read/write -> n/a
user_users_no: (no) -> no access
user_users_ro: read/only -> read/only
user_users_rw: read/write -> read/write
user_users_groupno_no: (no) -> no access
user_users_groupno_ro: read/only -> read/only
user_users_groupno_rw: read/write -> read/write
user_groupno_no: (no) -> no access
user_groupno_ro: read/only -> read/only
user_groupno_rw: read/write -> read/write
user_users_groupro_no: (no) -> no access [expected read/only]
user_users_groupro_ro: read/only -> read/only
user_users_groupro_rw: read/write -> read/write
user_groupro_no: (no) -> no access [expected read/only]
user_groupro_ro: read/only -> read/only
user_groupro_rw: read/write -> read/write
user_users_grouprw_no: (no) -> read/write
user_users_grouprw_ro: read/only -> read/write [expected read/only]
user_users_grouprw_rw: read/write -> read/write
user_grouprw_no: (no) -> read/write
user_grouprw_ro: read/only -> read/write [expected read/only]
user_grouprw_rw: read/write -> read/write
- omicron_persei8LuminarySo for Samba, a read/only user member of a read/write group gets not the most specific permission but the highest permission? Read/write? This makes the GUI confusing.
The fact that the permissions applied to group "users" even to non-members looks like a bug to me. Either you can't leave the group or you can and shouldn't get its permissions.
In above testing, when the group users don't have any permission, a user with no specific permission does not inherit the read/only permission from its group but does inherit the read/write permission. This is confusing.- chopin70Virtuoso
omicron_persei8 wrote:
So for Samba, a read/only user member of a read/write group gets not the most specific permission but the highest permission? Read/write? This makes the GUI confusing.
No, as I noted in my above edited post (under Reference), a user always takes precedence over group. A user should never escalate its permissions above what it is assigned by admin. In this case, GUI is admin.I am not sure about Samba, but I expected it to act like linux permissions in ACL mode.
In my case, if I want to forbid mount rights to a user, I have to uncheck every permission from every group, and don't give the user any permission. owner_user and owner_group must have r/w access, or no one will have access. This suggests that they use it like a no ACL scenario, which is not what we expected from the GUI and from the samba.conf file.
I tested many times and the user won't have access to the share
Basically. I unckeck permissions from groups and only set the permissions per user. Owner user and owner group must have r/w access. This is the actual situation, but maybe there are exceptions, since it is a bug
In anycase, the situation is clearly a bug
- omicron_persei8LuminaryCan you clarify which one of my expectations you disagree with please (the effective permissions sections in long post)?
In some situations, I have found that a read/only user member of a read/write group gets read/write access and at the same time a user with no specific permission member of a read/only group gets no access.- chopin70Virtuoso
omicron_persei8 wrote:
Can you clarify which one of my expectations you disagree with please (the effective permissions sections in long post)?
In some situations, I have found that a read/only user member of a read/write group gets read/write access and at the same time a user with no specific permission member of a read/only group gets no access.- read/only user member of a read/write group gets read/write access: should never occur as user privileges should be considered before group. This is something like escalating permissions
- a user with no specific permission member of a read/only group gets no access: this should be expected. We need however an "inherit permissions from group" as default to avoid a no access at all for any new user or a r/w access by default for every new user
Basically, things need to be clarified and made without any confusion + fixing the users escalating permissions depending on scrambled group issues for now.
As I posted above, here's what coud be done:Answer these 2 questions:
- what is the meaning of being able to setup separately the permissions of owner_user + the corresponding user and owner_group + corresponding group ? Which one will have the priority if we setup owner_user and the corresponding user differently ?
- what is the point of setting up group permissions if users of the actual group will have by default no read and no write access ?
Implement the following fixes:
- fix the current bugs of users / groups
- remove the unclear and redundant way allowing to set up two different access permissions for the same members/groups as in point 1
- in addition to the ro and rw options, add an option "inherit group permissions". That way, it is clear that:
- nothing is checked gives no mount access
- ro or rw if we need exceptions for the user. Else, "inherit group permissions" set by default for new users of a given group
- if we modify an existing group permissions, ask if we want to modify permissions for all its existing members or not (across all shares)
- if we modify the group for a given a user, ask if the user permissions should be changed to inherit the new group permissions, for all the shares
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!