[Samba] Best strategy to manage and backup Windows file permissions
Rowland Penny
rpenny at samba.org
Sun Mar 16 17:29:10 UTC 2025
On Sun, 16 Mar 2025 17:06:15 +0100
"R. Diez via samba" <samba at lists.samba.org> wrote:
> Hi all:
>
> I am a part-time Linux hacker planning a Samba server for a small
> business (after having recommended dropping Microsoft Windows
> altogether).
Please define 'Samba server'
>
> If I let users manage file permissions (Windows ACLs), it's going to
> be very hard after a while to tell who has access to what files and
> who hasn't. It looks like I am not the only one thinking along these
> lines:
>
> https://serverfault.com/questions/1173394/samba-best-practices-for-acl-s-for-windows-clients
I personally would hardly describe the smb.conf share on that page as
'best practice'
>
> https://unix.stackexchange.com/questions/757004/samba-acls-prevent-full-control
>
That one is a bit better except that it doesn't say that if you use 'vfs
objects = acl_xattr' in global then Samba will store the Windows
permissions in an EA.
> Besides, assuming that I manage to back up all files with their
> Windows ACLs (I guess by backing up the xattr's), I wonder whether
> the restore would work. The backup will probably have numeric SIDs,
> so a rebuilt Samba server would have to keep the same user accounts
> with the same SIDs, wouldn't it?
If you are going to backup anything, then yes, you do need to ensure
that the users are the correct ones, but this is fairly easy to achieve
by running an AD domain and always using the same idmap backend and
idmap config lines on all Unix domain members.
>
> So I am thinking that the best strategy would probably be to prevent
> users from changing file permissions at all. I could then agree with
> the users which groups should have which permissions where, and then
> set those permissions programmatically (with a script). For a small
> shop, I expect just a few rules like "under N:\some\where, only the
> 'managers' group should be able to read and write".
Good luck with that, on Windows any user that is a member of a group
that is an owner of folder/file can change permissions.
>
> After a change in the agreed permissions, I would just re-run the
> script to reset all file permissions. Should the server crash and get
> rebuilt from scratch, I could run the script to have the same
> permissions as before.
Problem is, do you really want to do this for a large number of
folders/files ? Some of which may have been remove, moved or added
after your last backup ?
>
> The script wouldn't use numeric SIDs, but names like "DOMAIN\Group1".
> If a group does not exist in the new server, the script would fail,
> so there wouldn't be much room for errors. If a group gets dropped or
> renamed, the script would flag obsolete rules immediately.
If you use AD then your group would always exist.
>
> Question 1) Can someone tell me what smb.conf settings I need for
> this kind of share/permission configuration?
>
> I searched the Internet, but found no conclusive answer yet, just
> people who tried this and that, and some of it seemed to work but not
> quite sure. See for the example the links mentioned above.
>
> Or maybe someone here knows where to find a tutorial or an example
> for this specific use case.
>
> Question 2) How would the script to set/reset permissions would look
> like?
Whatever you what it to look like, you are the one that is going to
have to write it.
>
> I am guessing that it would be a shell script with a few lines like
> this:
>
> samba-tool ntacl set xxx
It is going to have to be a lot more than just that.
>
> The trouble is, I couldn't find many examples to help work out the
> xxx part. The official documentation is rather sparse.
>
> In any case, I probably have to look-up the SIDs beforehand with
> "wbinfo --name-to-sid", right?
No, not really, properly set up a Unix domain member will always know
who the users or groups are.
I suggest you set up permissions from a Windows computer and do not
allow your normal users (members of the Domain Users group) full
control.
Rowland
More information about the samba
mailing list