We have a share which is owned by “domain admin” group and group “everyone” has no access. Thats working fine. What I now would like to add, is an additional active directory group with read only access to this share. Logging in with domain admin and trying to add a group to the share under right-click/properties/security I get an access denied.
Looking at the folder with linux shell I see:
How can I modify accordingly?
Hi
And a happy new year to you!
Using Cockpit:
Applications -> File Server -> Shared Folders -> ACL
Added in the group DokuWiki-Admins (just as example…)
Hope this helps
My 2 cents
Andy
Hi Andy,
partially it does help, thank you 
- as I must admit I overlooked the ACL line. So I added a group there and configured read-only access for it.
But in the subfolders of the share domain users seem to have full access, thus can still write to those folders, and that’s what I want to avoid. Checking in linux shell, I also can see why.
The problem is if I change to domain admins@ourdomain.tld in linux console with: "chown -R root:“domain admins@…” instead of domain users@… I do not get read access despite having added the user in the corresponding group which was configured with read access via the ACL field 
Hi
Normal Linux permission commands are not ACL capable…
Here’s a good help for the subject in german…
In end effect, you can’t use the usual chown / chmod, but you can still do a recursive, like with chmod or chown…
So keep the standard Linux permissions as they are, but use ACLs!
My 2 cents
Andy
Thanks Andy, I am still reading but “das ist mir zu hoch”
Have to study further, as I don’t get it yet.
I am still about to find out how I remove the write attribute from the group “domain users@ourdomain.tld”
getfacl /var/lib/nethserver/ibay/nethshare/folder/
getfacl: Removing leading '/' from absolute path names
# file: var/lib/nethserver/ibay/nethshare/folder/
# owner: root
# group: domain\040users@ourdomain.tld
# flags: -s-
user::rwx
group::rwx
other::---
Tried with:
setfacl -d -m group:domain\040users@ourdomain.tld:g-w /var/lib/nethserver/ibay/nethshare/folder/
resulted in:
setfacl: Option -m: Invalid argument near character 7
Hi
Yes, ACLs make UN*X permissions really complicated, especially if you’re old school!
Just a word of warning: What you can’t do with normal permissions: “lockout root”, as root always has permissions everywhere: You can lockout root from the system!
Make sure you have a full backup!
My 2 cents
Andy
Thanks for the warning. The folder I try to modify is our rsynced share from our locally shared data. The goal is that we only have read access to them, so they keep save from overwriting/being encrypted by malware, while we are still able to access them fast in case someone accidently deleted something.
Whats wrong with my setfacl try? I dont get it. May it be because of the long group name… I will investigate further and report back if I found the solution.
Whatever ACL I set in nethserver gui is only for the share itself but not for its subfolders. If I add domain group xyz and limit it to read access in gui, I can see that group in linux shell with getfacl set as default group (on the share but not on the subfolders). And it indeed respects read or read-write access, but only for the share itself, and not recursively.
So a user in xyz group can only read in nethshare but can still write in nethshare/subfolder… 
AFAIK there is a Recursive option for the setfacl command: setfacl -R
Can’t you use that?
Well it does not work in my case. I don’t know how the command should look like, but I tried:
setfacl -R -m g:domain\040users@ourdomain.tld:r-x /var/lib/nethserver/ibay/neth-share but the result was
setfacl: Option -m: Invalid argument near character 3
I must do something wrongly…
What I see is that the group I added in ACL via GUI (domain users in this case trying to restrict it to read-only, but I also tried other groups with the same result) is only visible as default-group on the share but not on a subfolder of the share:
getfacl /var/lib/nethserver/ibay/neth-share/
getfacl: Removing leading '/' from absolute path names
# file: var/lib/nethserver/ibay/neth-share/
# owner: root
# group: domain\040admins@ourdomain.tld
# flags: -s-
user::rwx
group::rwx
group:domain\040users@ourdomain.tld:r-x
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:domain\040users@ourdomain.tld:r-x
default:mask::rwx
default:other::---
getfacl /var/lib/nethserver/ibay/neth-share/subfolder/
getfacl: Removing leading '/' from absolute path names
# file: var/lib/nethserver/ibay/neth-share/subfolder/
# owner: root
# group: domain\040users@ourdomain.tld
# flags: -s-
user::rwx
group::rwx
other::---
Well almost the same with other groups. The difference is:
adding say group xyz -> it becomes default group xyz on the share, but on subfolder the group (there is no default group on the subfolder, just a group) remains domain\40users@ourdomain.tld and there is no xyz.
Without commenting nor having a opinion on the solution;
you probably need to put the hole group name in double quotes ie:
setfacl -R -m g:"domain\040users@ourdomain.tld":r-x
I was sure, I had tried this but apparently not correctly. This time that worked, but I still am able to write to write to the subfolders.
setfacl -R -m g:"domain\040users@ourdomain.tld":r-x /var/lib/nethserver/ibay/neth-share/subfolder/
getfacl /var/lib/nethserver/ibay/neth-share/subfolder/
getfacl: Removing leading ‘/’ from absolute path names
# file: var/lib/nethserver/ibay/neth-share/subfolder/
# owner: root
# group: domain\040users@ourdomain.tld
# flags: -s-
user::rwx
group::rwx
group:domain\040users@ourdomain.tld:r-x
mask::rwx
other::—
I guess, I have to modify the user: group: and mask: somehow, which all are rwx?
I really would like to restrict users from writing to the subfolders of above share, so may I ask once again for some help with that problem?
signal-event ibay-reset-permissions sharedfoldername) or from old server manager (if no custom permissions were set manually)#bug?
I will do so asap. But first things first. What is it all about with this share.
We have a local server A with its shares where users can access with read-write permissions, server A also provides the roaming profiles and redirected folders among other things.
Then there is remote server B which has a share that should only be accessible limitedly. Domain users should not be able to write to this share. With a cronjob on server B the folders from server A are rsynced every quarter of an hour.
The corresponding command for the rsync job is:
sync -a -e ‘ssh -p customportnumber’ root@servera:/var/lib/nethserver/ibay/Folder1/ && sync -a -e ‘ssh -p customportnumber’ root@servera:/var/lib/nethserver/ibay/Folder2/ and so on.
On weekends we add the option --delete to rsync so deleted files on server A get deleted once a week on server B.
I started asking myself if it could be because on server A the users have read-write access - could that be the reason why the users can still write on the share on server B is the resync after all?
Would I have to modify the rsync options in order to keep access rights of the destination folder instead?
In any case I check and write down the share and sub-folder permissions but will have to do the reset later.
Share:
getfacl /var/lib/nethserver/ibay/nethshare
getfacl: Removing leading '/' from absolute path names
# file: var/lib/nethserver/ibay/nethshare
# owner: root
# group: domain\040admins@ourdomain.tld
# flags: -s-
user::rwx
group::rwx
group:domain\040users@ourdomain.tld:r-x
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:domain\040users@ourdomain.tld:r-x
default:mask::rwx
default:other::---
Subfolder:
ls -l /var/lib/nethserver/ibay/nethshare/subfolder1/
total 40
drwxrwsr-x+ 50 root domain users@ourdomain.tld 8192 Dec 28 16:27 Folder2
ls -l /var/lib/nethserver/ibay/nethshare/subfolder1/Folder2
-rw-rw----+ 1 user2@ourdomain.tld domain users@ourdomain.tld 0 Aug 16 2009 filename.pdf
(...)
getfacl /var/lib/nethserver/ibay/nethshare/subfolder1/
getfacl: Removing leading '/' from absolute path names
# file: var/lib/nethserver/ibay/nethshare/subfolder1/
# owner: root
# group: domain\040users@ourdomain.tld
# flags: -s-
user::rwx
group::rwx
group:domain\040users@ourdomain.tld:r-x
mask::rwx
other::---
I checked again and while I indeed cannot create a subfolder in windows under \\serverb\nethshare I can create files and folders under \\serverb\nethshare\subfolders
After the snapshot and reset of the accessrights on the share as suggested, immediately checked and indeed now it behaves correctly - read only for domain users members. The question remains though if the problem is comming from the rsync. I will check later after the next rsync is done and also will create a new folder on servera and see how the access rights are after rsync to serverb.
You could also try to create a new share from old server manager and from cockpit and see if permissions/acls differ.
I think it really is rsync that reverses some of the access rights, as it works as intended but a bit later (after next rsync) the access rights are increased, meaning, I can start writing on folders again. So I have to find out if there is a way to tell rsync to respect access rights from destination instead of the actual behaviour?
Hi
See the sample command from my “Fundus”…
rsync -avzu --no-perms --no-owner --no-group /mnt/Backup-Dicom/ /mnt/Backup-Dicom2/
The three shown options helped me in an earlier case…
–no-perms --no-owner --no-group
As rsync doesn’t try to change any perms, the folder values should be valid…
Worked for me, with one or two small exceptions…
My 2 cents
Andy
Is the resync command with the -p, --perms (preserve permissions) parameter?
See https://ss64.com/bash/rsync.html