ACL yet on fileshare/folders after removing via Cockpit

Nethserver 7.9 with local AD

Short Version:

If i set an ACL on an Fileshare via Cockpit and remove tis ACL later (again via Cockpit),
the ACL Entry in Cockpit in gone but the ACL are present yet.

After “reset permissions” on Cockpit for this share, the folders have the ACL yet.
Is that desired or to be expected? Or is this an Bug?

If this is an Bug, i can write an long version.

Regards yummiweb

1 Like

I cannot reproduce.

When I create a fileshare “test” and set some ACLs I can see them with

getfacl /var/lib/nethserver/ibay/test

After removing some ACLs in cockpit, I don’t see them with getfacl anymore.

Does the share contain many files/folders? It may take some time for the reset.

Dear mrmarkus,
thank you for fast response.

The original share (as the problem occurs) contains indeed many files and folders,
but i can reproduce the problem wit a complete new share on a different maschine.
(done this some minutes ago)

My steps to reproduce (sorry for the detailed outputs):

  • Create an Group e.g. “share_test” for the planned Fileshare e.g. “TEST” (via Cockpit).
    I do this because i use mostly the Posix Rights management, for fileshares, not the ACLs.

  • Add an User (e.g. me) to this Group

  • Create an Fileshare “TEST” (via Cockpit), the Ownergroup should be “share_test”.
    The ACL is in standard (Ownergroup read/write, Everyone none).
    Other settings: no Guest access, monitoríng on, searchable, network trash, hold copys from files with same name (my GUI is in german)

  • Create an file and a folder in this Share (without special acl)
    touch /var/lib/nethserver/ibay/TEST/testfile1
    mkdir /var/lib/nethserver/ibay/TEST/testfolder1
    (done via root but no difference via smb)

getfacl says for “TEST”:

# file: var/lib/nethserver/ibay/TEST
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
group::rwx
other::—

getfacl says for “TEST/*” (2 objects):

# file: var/lib/nethserver/ibay/TEST/testfile1
# owner: root
# group: share_test@mydomain
user::rw-
group::r–
other::r–

# file: var/lib/nethserver/ibay/TEST/testfolder1
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
group::r-x
other::r-x

  • Set now an ACL for the Fileshare “TEST” via Cockpit,
    set a existing user e.g. “tester” with readonly rights.

  • Create again files and a folders in this Share (with this acl)
    touch /var/lib/nethserver/ibay/TEST/testfile2
    mkdir /var/lib/nethserver/ibay/TEST/testfolder2
    (done via root but no difference via smb)

getfacl says for “TEST”:

# file: var/lib/nethserver/ibay/TEST
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
user:tester@mydomain:r-x
group::rwx
mask::rwx
other::—
default:user::rwx
default:user:tester@mydomain:r-x
default:group::rwx
default:mask::rwx
default:other::—

getfacl says for “TEST/*” (4 objects):

# file: var/lib/nethserver/ibay/TEST/testfile1
# owner: root
# group: share_test@mydomain
user::rw-
group::r–
other::r–

# file: var/lib/nethserver/ibay/TEST/testfile2
# owner: root
# group: share_test@mydomain
user::rw-
user:tester@mydomain:r-x #effective:r
group::rwx #effective:rw-
mask::rw-
other::—

# file: var/lib/nethserver/ibay/TEST/testfolder1
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
group::r-x
other::r-x

# file: var/lib/nethserver/ibay/TEST/testfolder2
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
user:tester@mydomain:r-x
group::rwx
mask::rwx
other::—
default:user::rwx
default:user:tester@mydomain:r-x
default:group::rwx
default:mask::rwx
default:other::—

O.k, the new files and folders have the new ACLs, the old have no ACLs.
Until now this is normal, i think.

  • Now “reset permissions” for this share via Cockpit

getfacl says for “TEST/*” that all files and folders have ACLs now, as expected:

# file: var/lib/nethserver/ibay/TEST/testfile1
# owner: root
# group: share_test@mydomain
user::rw-
user:tester@mydomain:r–
group::rw-
mask::rw-
other::—

# file: var/lib/nethserver/ibay/TEST/testfile2
# owner: root
# group: share_test@mydomain
user::rw-
user:tester@mydomain:r–
group::rw-
mask::rw-
other::—

# file: var/lib/nethserver/ibay/TEST/testfolder1
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
user:tester@mydomain:r-x
group::rwx
mask::rwx
other::—
default:user::rwx
default:user:tester@mydomain:r-x
default:group::rwx
default:mask::rwx
default:other::—

# file: var/lib/nethserver/ibay/TEST/testfolder2
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
user:tester@mydomain:r-x
group::rwx
mask::rwx
other::—
default:user::rwx
default:user:tester@mydomain:r-x
default:group::rwx
default:mask::rwx
default:other::—

  • Remove the ACL Entry for user “tester” via Cockpit (press the “x”)

The ACLs are present until now , this is a normal behavior i think.

But then…

  • AGAIN “reset permissions” for this share via Cockpit

and getfacl says for “TEST/*”:
(the folder have the ACLs yet, the files have no ACLs)

# file: var/lib/nethserver/ibay/TEST/testfile1
# owner: root
# group: share_test@mydomain
user::rw-
group::rw-
other::—

# file: var/lib/nethserver/ibay/TEST/testfile2
# owner: root
# group: share_test@mydomain
user::rw-
group::rw-
other::—

# file: var/lib/nethserver/ibay/TEST/testfolder1
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
group::rwx
other::—
default:user::rwx
default:user:tester@mydomain:r-x
default:group::rwx
default:mask::rwx
default:other::—

# file: var/lib/nethserver/ibay/TEST/testfolder2
# owner: root
# group: share_test@mydomain
# flags: -s-
user::rwx
group::rwx
other::—
default:user::rwx
default:user:tester@mydomain:r-x
default:group::rwx
default:mask::rwx
default:other::—

And so i was running in this problem:

I have an fileshare with read/write access for some users (via Group membership in this fileshare-ownergroup) This fileshare has no ACL set.

A new user should become readonly access first, so i added an ACL entry for this fileshare (via Cockpit). But there was some content the user cannot read. So i have “reset permissions” for this share via Cockpit. The new user could now read as axpected.

Some days later the new user should become full access to the share, so i removed the ACL for this user (via Cockpit) and set the new user now in the ownergroup of this fileshare (without ACL).

The new User could do some things now and some not. (smb share over macos high sierra)
He could add folders or copy file in this share as expected, but he could not save MS Office documents in this Share. Error message says: No rights to write or not enough space on share (or something like that)

At first I suspected the Office program, but on other fileshares there was no problem for this user (with no special ACLs set for him before). Therefore I looked at the user rights of the Fileshare via Console.
The ACL with the readonly rights for the new user was still here on folders on files and files.
This was maybe expected, but i have forgotten this because i rarely use ACLs.

So i have “reset permissions” again for this share via Cockpit. But Problem persists.
The ACL with the readonly rights for the new user was still here on folders (and maybe on files, i dont know anymore).
So i have reset the complete path via “setfacl -Rb /var/lib/nethserver/ibay/FREIGABE”.
After that the Problem was gone.

Regards
yummiweb

I can confirm the issue.
If you delete an ACL of a share and reset it, the ACL is still there.
I found that it changes when you delete an ACL and add another one.

In other words, a deleted ACL is not respected by the reset.

I think it’s a bug. Maybe it’s enough to clear the ACLs with setfacl -Rb before the reset. Maybe we need another button? :thinking:
It’s always a problem to change such things because people may rely on the actual reset procedure…
@davidep what do you think?

As a workaround you may:

  • Create groups “test_fullaccess” and “test_readonly”
  • Set the owning group to “test_fullaccess” allowing read and write
  • Add an ACL for “test_readonly” with read-only permission
  • Move the users to the corresponding group, a user in both groups has full access
  • Restart smb (the only way I found to apply the ACLs immediately)

I can confirm, that the workaround works for me.
The group ACL still persits (after reset permissions in Cockpit),
but without an user ACL the (different) user permissions (ro) cannot override the group permissions (rw).

I think, a separate Button like “remove all ACLs with different settings” could be the best of two worlds,
the old behavior wich kept "old ACLs and the possibility to bring the ACLs in sync with the settings in Cockpit.
(a double step process, first removing the ACLs and then trickle down the ACLs like in Cockpit “reset permissions”)

Thank you for reporting this issue @yummiweb @mrmarkuz . I’m trying to sort out the “right” behavior :thinking:


Edit

Back to this, I can reproduce this behavior. It is like the ACL is reset to files only, whilst directories are not reset. I think this is not what is documented and it is not what I’d expect:

At any time, the Reset permissions button propagates the shared folder UNIX permissions and POSIX ACLs to its contents. – https://docs.nethserver.org/en/v7/shared_folder.html#authorizations

BTW that docs page needs to be updated for the Cockpit UI.

1 Like

Thanks again! I confirm it is a #bug, now filed here

1 Like

The fix is available from the testing repository

yum --enablerepo=nethserver-testing update nethserver-samba

@yummiweb @mrmarkuz could you check it out? Does it solve your original issue?

1 Like

Yes, for me it works correctly now.
With the fix, deleted ACLs are correctly not set anymore when resetting a share.

1 Like

Thank you @mrmarkuz, the bug fix has been released!

3 Likes

Great! Thank you for the quick response and the great work!

Regards
yummiweb

3 Likes

This topic was automatically closed after 3 days. New replies are no longer allowed.