ReadOnly SMB share without messing/downgrading ACLs

Hi,

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?

How can I accomplish what I want?

Why not just use snapshots?

There is an “Export Read Only” setting in the Advanced Options for the share. That works.

And like you I’m confused by the Share Permissions, having found out that it will not honor a READ for @everyone setting.

2 Likes

What do you mean that it doesn’t honor READ? Please give more details.

Setting the Share ACL with a single entry,

@everyone READ ALLOWED

does not make the share read-only, as one would think (tested this on a couple of 24.04 boxes).

I have not investigated further since it is possible to make the share read-only via Advanced Options.

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.

Maybe because the SMB Share ACL permissions are additive?

Without any restrictions for @everyone, giving them read permissions does not automatically deny them any other permissions.

Perhaps you would have to DENY @everyone write, delete, modify, and so on, and then grant them read.

zfs set readonly=on pool/dataset

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.

I’ll need more information on reproduction case. Are you perhaps not re-mounting the share after changing the share ACL?

What is output of sharesec --view <share name>?

Ooops. Never thought of it… :grimacing: :grimacing:

Sorry, it may be that it is as simple as that, in which case I apologize for your trouble.

FWIW, that’s what 30 years of working with Windows will do to your troubleshooting skills… (first version was NT 3.5, in 1994)

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.

2 Likes