[TUTORIAL] Samba Fileserver (and probably DC) in unprivileged container

[jochen.korge]

Hi,
after some trial and error I found a way to get Samba running in an unprivileged Container.

This isn´t a "copy paste tutorial" but some hints to the more obscure knobs you have to turn.
Our Setup consists of a Proxmox ZFS Backend and a SAMBA Based AD-Domain (hosted on a different Server)
I found several Posts/Articles stating, that it won´t work due to the "security Namespace" and then I stumbled over this Mail from the samba mailing list. It addresses the same issue but from the Samba Domain Controller point of view.

Preparation on the host​

# not sure if necessary
zfs set aclmode=passthrough aclinherit=passthrough acltype=nfsv4 our/dataset

cat /etc/pve/lxc/100.conf
[...]
# We map Domain Users via rid-Mapping to UID 1000000-1999999 on both systems, so the UIDs should stay the same.
lxc.idmap: u 0 100000 100000 #0 100k 100k Map user 0 to 99999 in container to 100k to 199999 on Host
lxc.idmap: g 0 100000 100000 #0 100k 100k
lxc.idmap: u 1000000 1000000 1000000 #1m 1m 1m keep the same UIDs for the Users from 1m to 1999999
lxc.idmap: g 1000000 1000000 1000000 #1m 1m 1m
[...]
# And we need to bind-mount our Data into the Container
mp0: /our/data/we/want/to/share/,mp=/srv/testshare,mountoptions=nodev;noexec;nosuid

Samba Config in the Container​

cat /etc/samba/smb.conf
[global]
[...]
        idmap config MYDOM : backend = rid
        idmap config MYDOM : range = 1000000-1999999
[...]
[testshare]
        path = /srv/testshare/
        vfs objects = posixacl nfs4acl_xattr acl_xattr
        nfs4acl_xattr:xattr_name = user.nfs4_acl #the trick: if security.nfs4_acl namespace is prohibited, just don´t use it
        nfs4acl_xattr:encoding = nfs
        nfs4acl_xattr:version = 41
        nfs4acl_xattr:default acl style = windows
[...]

Probably some of the options/configurations can be omitted, but this way it worked for me

 

[shh]

Hello,
this doesn't seem to work on a Debian Bookworm system with current Version 4.17.8-Debian (for me).
If I use these options, *no* ACLs are set, never.

zfs create share/test
chgrp 3000000 /share/test/
zfs set aclinherit=passthrough aclmode=passthrough acltype=nfsv4 share/test
zfs get aclmode,aclinherit,acltype,xattr share/test
NAME        PROPERTY    VALUE          SOURCE
share/test  aclmode     passthrough    local
share/test  aclinherit  passthrough    local
share/test  acltype     nfsv4          local
share/test  xattr       sa             inherited from share
# Now setting Admins and some non-default groups for this folder in the MMC under Windows. Then:
ls -l /share/
drwxr-xr-x   2 root BUILTIN\administrators  2  1. Jul 13:49 test
getfacl test
# file: test
# owner: root
# group: BUILTIN\\administrators
user::rwx
group::r-x
other::r-x

Note the missing + for this folder after ls.
This was checked *after* I set inherited settings for Admins and other groups on /share/test. However, the access settings are shown in Windows, as I set them, but other users of the groups aren't able to read/write according to my ACLs.
(ACLs would be set if I stay in posix for zfs and vfs objects)

Does somebody know, what changed since Feb? Or what I'm doing wrong?
Best regards...

 

[RolandK]

thank you

please keep in mind that zfs currently does not fully support lxc containers

have a look at https://github.com/openzfs/zfs/releases/tag/zfs-2.2.0-rc1 , it's referencing 3 github tickets regarding this

also have a look at https://forum.proxmox.com/threads/r...eged-container-uid-gid-remap-strategy.129684/ , it could perhaps be useful when running containers with samba inside and shares bind mounted to the host. https://forum.proxmox.com/threads/r...eged-container-uid-gid-remap-strategy.129684/

 

[shh]

Thanks for the hints!
However, I don't think this is LXC or idmapping related, because even on the core system with root, ACLs aren't written with this config.
It seems that every time I activate nfs4acl_xattr or acltype=nfsv4, the ACLs are gone.

And afaik, we don't have proper NFSv4 support on Linux, yet. Well, TrueNAS Core has since a few months. I'm wondering how the above had worked anyway.
Or does Proxmox include the ACL patches for the Linux kernel and SAMBA from TrueNAS?
E.g.:
https://github.com/truenas/linux/commit/812966f278f50b801428d5b1c78181a22ce584bd
https://github.com/truenas/samba/pull/79
https://github.com/truenas/zfs/pull/52

 

[mazura]

Is this guide specifically for ZFS? Because I'm using ext4, not using ZFS and it was surprisingly easy to get samba running on unprivileged container pointing to a bind mount without much fiddling. Even got Filebrowser and Samba all working together.

 

[shh]

I'd think it's just ZFS related, because our thread starter mentioned NFSv4 ACLs and a specific nfs4acl_xattr configuration for SAMBA which in February somehow lead to a proper nfsv4-acl passthrough?!
But, I just don't know. I just couldn't reproduce the effect and am a little doubting, because our kernel (without the TrueNAS patches) still isn't able to properly use ntfsv4-acl for a long time. (discussions and refusal of the kernel people regarding accepting anything besides PosixACL last many years already)
But, thanks for the hint to use EXT4 alternatively!

 

[jochen.korge]

I think I have to clarify:
There is no working passthrough! Only SMB respects those ACLs. Linux permissions stay at UGO (or whatever was specified)!

What happens is: Samba writes Permissions to another XATTR-Namespace (User in this case). So Samba-ACLs are written somewhere, where Linux does not expect ACLs so they aren´t respected by Linux! This Namespace isn´t protected, so I expect, that any Linux-User with write permissions is able to arbitrary change the ACLs!
This is acceptable for our Use-Case, it might be a bit security concern for yours.

Somehow I can not Edit the first post. I think, this clarification should be part of it. Can any Mod please edit for me?

EDIT:

Preparation on the host

cat /etc/pve/lxc/100.conf
[...]
# And we need to bind-mount our Data into the Container
mp0: /our/data/we/want/to/share/,mp=/srv/testshare,mountoptions=nodev;noexec;nosuid

I just realized, that the mount doesn´t work if you want to share zfs child-datasets. Then you need

lxc.mount.entry: /our/data/we/want/to/share/recursive/ where/to/in/container none rbind,create=dir,... 0 0
# important: no / before mount target!