Shared Folder ACL applied to a group sometimes not respected

Bug
, , ,
#21

It works better with the testing package. Tested assigning ACL to a user, to a group of users, and to a group of users and (sub)groups …but there seem to be some corner cases when comparing these actions:

  • Allowing write permissions to owning group + read-only ACL to a user of that group = user cannot write
  • Allowing write permissions to owning group (Domain Users) + read-only ACL to a domain user = user cannot write
  • Allowing write permissions to owning group (Domain Users) + read-only ACL to a group which holds a domain user as a member = user can write

Other notes (just for the record):

  • ACL entries without assignments are removed from the list.
  • Subdirectories retain previous permissions (unless reset permissions button is used).
1 Like
#22

We should compare them with POSIX ACL semantics. What you report seems compatible with these rules:

  • user ACL overrides group ones
  • owner group overrides ACL group entry

What you report here is the expected behavior. Do you see any possible enhancement?

1 Like
#23

Thanks, I didn’t know.

About the other notes (just a reminder) I think it’s ok.

#24

If possible, reinstall. Bugs must be reproducible, otherwise they can’t be fixed, or are not bug at all :wink:

1 Like
#25

Me too :laughing:

I was guessing…

1 Like
#26

The issue is solved but i still have some concerns about the use of ACLs.

Basically ACLs should be used only to handle very special cases, but I see that many Windows system administrators are used to always set the ACL over shared folder.

I was wondering: should we add a clarification inside the administrator manual with a usage scenario?

( Relevant page: http://docs.nethserver.org/en/v7rc/shared_folder.html )

1 Like
De-install webproxy(squid)
#27

A post was split to a new topic: Web-proxy is interfering with the samba fileserver

#28

This worked for me

#29

Was fixed here