I have a setup running on SCALE ElectricEel 24.10. We are a mixed linux/win household, but I keep things SMB to KISS. I have several user accounts for family members and they each have their own personal SMB share with ACL set for them and that is all fine. However, we have a large storage share where we have all our common stuff (pictures, videos, etc) and there is no trust issue here so we all had write access to it via other:rwx and share ACL set to FULL on @everyone.
I would like to change that. Kids are now big, experimenting on their boxes, I fear a potential ransomware pillaging their boxes (and by extension encrypting our storage) and its kind of too big to constantly back it up. I would like to make it read only, but without messing with ACLs. I will make a separate staging share with full access where they can copy files they want me to incorporate into storage. I can ssh to NAS and use mc to move files around from staging to storage, but for that i need access on my account and I want my account to also be readonly via share.
I tried changing share permission to READ for @everyone, but that did not make it read only, which lead me to wonder what that permission is really for?
Ok, fixed it this way. The thing is this option was disabled because I used “default share parameters”. I flipped it to NFS/SMB and now I can enable the box.
I’ll try that in the future, but it seems a bit counterintuitive - when sharing via Windows Server, having a single share ACL entry with “Read” permission for the group “Everyone” effectively disables writing to the share.
Also, a “Deny” permission in Windows supersedes any “Allow” ACL, so if you did as suggested nobody would be able to access the share.
Of course, Linux does its own thing, but still, it is a bit confusing.
It’s important to bear in mind that some security-related items are only determined during the initial SMB tree connection. For example:
calculations of maximum access based on share ACL
determination of unix token (group memberships, etc)
Actual file ACLs are evaluated at time of operation, but this is based on unix token.
I removed the solution checkbox from this thread because the statement about share ACL not being evaluated properly is incorrect.