ZFS ACL trouble on ZFS with a bit of Samba

Dear all,

I started using ACL´s on ZFS in order to use it in Samba 4.13. Created zroot under FreeBSD 12.2 RELEASE and upgraded to 13 RELEASE with OpenZFS. Switched xattrs from "on" to "sa" initially, but back to "on" after I ran into trouble and read about incompatibilities between the different ZFS implementations.

Besides the datasets created by the installer, I have several datasets with different settings (e.g. compression, maybe encryption later) which go under zroot/<name> mounted under /eigene/<name> while /eigene/ is a folder under zroot/ROOT/default. After some confusing problems (ACL´s had no effect) I freshly re-created a dataset (zroot/tmp), with xattr=sa, set ACL´s from scratch and tried to work with it.

Problem I have is that my ACL´s, set e.g. with
Code:
setfacl -a0 user:vmPDC:full_set:fd-----:allow /eigene/tmp

and result in

Code:
root@betzisbox# getfacl /eigene/tmp
# file: /eigene/tmp
# owner: root
# group: wheel
        user:vmPDC:rwxpDdaARWcCos:fd-----:allow
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWc--s:fd-----:allow
         everyone@:rwxpDdaARWc--s:fd-----:allow

do not have any effect - such as:

Code:
sudo -u vmPDC ls /eigene/tmp
ls: /eigene/tmp: Permission denied

This is strange, since as I understood, the everyone@-permission should already have been enough to let user "vmPDC" (such as any other user) access that folder. I tested that as well before the run with the dedicated entry for "vmPDC", which failed with the same error.

A listing of the "classic" permissions shows "+"es, which I think is reserved for POSIX ACL´s while I use NFSv4 only.

Code:
ls -l /eigene

drwxr--r--+ 65 root  wheel   68 Jun 25 01:22 spiele
drwx------+ 28 root  wheel   74 Jun 25 01:21 system
drwxrwxrwx+  9 root  wheel   45 Jun 29 13:38 tmp

So I´m confused now. Is there any way to determine whether ACL´s are working correctly?
I also were not able to find a comprehensive guide or similar for that topic: ACL´s on ZFS under FreeBSD 13.

Greetings from hell
Betzi
 
Quick update. Verified my assumptions on the behaviour of ACLs & everyone@ ACE with a fresh install of 13 RELEASE@Virtualbox.
Everything works as expected initally which means the original machine migrated from 12.2 to 13 seems to be faulty and I would guess the different ZFS implementations are the cause, here.

Will run an additional check on the original machine with deactivated winbind - just to be sure - but I think this is a bug and I should file a bug report..
 
Have you tried using a design tool to think things through? Like a diagram? Samba on top of ZFS is not impossible - if you pay attention. One design strategy that I can suggest (to make things a bit simpler) is to correlate specific SAMBA shares to specific ZFS datasets. That will make it easier to troubleshoot whether ZFS dataset-specific permissions are giving SAMBA a hard time. After that, you should be able to troubleshoot your SAMBA share-specific ACLs to your heart's content. You may discover that it's not really a bug, but incompatible permissions between systems.
 
No diagrams or tools were involved since a) this is a private toy project and b) my folder structure is pretty straigthforward and was designed with Samba/CIFS in mind, years ago.
Stuff basically goes into folders based on the permissions/visibility needed and since I use ZFS, it is mapped into datasets 1:1.

Please note that the problem exists with local users in /bin/sh. Having no (more) access in SAMBA was the initial trigger to check permissions locally but now even my local users are failing to access folders which are located on another dataset as the ones I manipulated in Samba.
As you can see by my above code, local user vmPDC was not able to access a folder with the following ACE: user:vmPDC:rwxpDdaARWcCos:fd-----:allow . As I understood - and was successfully able to test in a FreeBSD13 VBox - this should be enough to grant full access for that user.

What do you mean with ZFS dataset specific permissions? I set permissions on the base folder (where dataset is mounted) and all the content. Again here, everything is pretty straightforward. 1 folder - 1 permission set.

What do you mean with ZFS dataset specific permissions? Are there permissions for the datasets themselves - that I´m not aware of - or do you assume that within the dataset there is a difficult hierachy of permissions, causing the problem?


Anyway. You brought me to 1 idea. I´ll check whether the setting of ACL´s with Windows Clients (which I actually did, before everything messed up) over Samba had an effect.
Basically, that was the reason why I asked wheter there are tools to check whether ACL´s do work correctly. There is something messed up since things that are supposed to work - ls by an account with full_set permissions - do not work.
My question here is, how can I find the root cause? Are there ways to inspect xattrs - e.g. where they are stored.
 
What do you mean with ZFS dataset specific permissions? I set permissions on the base folder (where dataset is mounted) and all the content. Again here, everything is pretty straightforward. 1 folder - 1 permission set.

What do you mean with ZFS dataset specific permissions? Are there permissions for the datasets themselves - that I´m not aware of - or do you assume that within the dataset there is a difficult hierachy of permissions, causing the problem?
Yes, there are ZFS dataset specific permissions. If Samba process does not have enough permissions to access the underlying ZFS dataset, the Samba process will complain. smbd is a separate user on your system - check Samba's post-install message. And ZFS dataset-specific permissions are different from regular UNIX folder permissions. This is why - even for a toy project like what you outline, you do need to diagram out the design and think things through. Then troubleshooting is not a crapshoot of random places to check.
 
In think you posted the wrong link. It's about delegation of ZFS management permissions.
I don't think the possibility of a certain user X to ls within a datasets content are affected by X's permission to snapshot, or do I misunderstand something?
 
My point was was that smbd process/daemon is a separate user. Just do a # cat /etc/passwd | grep smb to verify what I'm saying. This smbd user is the one that needs correct permissions to access the ZFS datasets. Once that access is established for the smbd user, then you can represent those datasets as SAMBA shares. This comes back to what I was saying earlier about paying attention and matching things up in the design.
 
I don't have access to the machine atm but I was able to connect in Samba before I made the initial post.
But as said, that only worked for some of the users while others couldn't.

smbclient \\localhost\schorle -U riesling succeeded and ls showed dir contents while smbclient \\localhost\schorle -U mueller could log in but got "No permission" when ls folder contents.

To check wheter the error is from Samba or from the ACL's I checked permissions directly in the shell. T
his produces the same result even when setting a full_set ACL on user level, which is a bug as far as I can judge.
 
I use standalone Samba 4.13 and the smbd user in my case (default case) is root. Should be quite tricky to run Samba as Non-Root, anyway because of the ports < 1024 and the ability to act with the permissions of the logged in users such as "mueller" or "riesling" (which are only examples as every wine drinker may know). Do you have any running examples where Samba is ran as non-root (just for curiosity)?
 
I use standalone Samba 4.13 and the smbd user in my case (default case) is root. Should be quite tricky to run Samba as Non-Root, anyway because of the ports < 1024 and the ability to act with the permissions of the logged in users such as "mueller" or "riesling" (which are only examples as every wine drinker may know). Do you have any running examples where Samba is ran as non-root (just for curiosity)?
I don't have a running example (I'm in the middle of something else), but I can suggest reading the Handbook - it does have a section devoted to setting up Samba. That section is written with the assumption that FreeBSD has been set up with just the minimum defaults to have a running system - and that would include accepting the ZFS pre-selection.
 
https://docs.freebsd.org/en/books/handbook/network-servers/#network-samba is about Samba from ports since, according to handbook, sharesmb property of ZFS isn´t supported under FreeBSD. Which makes sense since Samba is not part of the base system. The handbook doesn´t tell about running Samba as non-root and there seems to be no builtin option for that or in the rc script.

So I don´t see the relation between ZFS and Samba port, which operates on paths and not on datasets. It does interact with the file permissions and ACLs of ZFS but on folder and file level if I´m not mistaken.

But agreee, reading the handbook is always a good idea. The quality of the handbook is one of the reasons why I prefer FreeBSD over Linux.
 
Here we go:

20.4.4.1. Getting and Setting Share Properties​

Two commonly used and useful dataset properties are the NFS and SMB share options. Setting these define if and how ZFS datasets may be shared on the network. At present, only setting sharing via NFS is supported on FreeBSD. To get the current status of a share, enter:....

You are right, ports or packages. I meant ports (or depending packages) as opposed to base.
But anyway - there seems to be no standard way to run samba as a normal user and I do not see how Samba would directly be affected from dataset properties except the non-supported sharessmb property.
 
I found this just by googling 'zfs sharesmb freebsd'... worth a try. Basically, tell Samba to ignore ZFS datasets, and operate on the regular folders like /usr/home/.

FWIW, the complaints about sharesmb not working on FreeBSD - that was from a bout 10 years ago. By now the situation should be fixed.
 
Exactly what I was saying. Samba port or pkg operates on folders, not on datasets.
(But there are some modules for the underlying filesystems like "vfs object = zfs_acls". They interact with FS specific properties if one needs advanced capabilities like setting permissions from Windows clients but they deal with file and folder properties - their ACLs - and not those of the datasets.)

Unlike Solaris and family, there is no kernel mode SMB/CIFS in FreeBSD. So sharesmb, if implemented, would result in an include into smb4.conf pointing to the mountpoint (=folder) of the dataset rather than the dataset itself. That's meant here with exporting them.

That sharesmb isn't working is clearly stated in the current handbook, that you (!) referred to. I even marked it in bold. I can not check that at the moment nor paint a diagram explaining that.

Let's just state something I learned in struggling with that for anyone dealing with the matter in the future: Be sure to use the right vfs objects for your shares if dealing with ACLs and the right acltype if working with ZFS.
 
Windows clients only need login permissions, and R/W permissions. Those are independent of ZFS. You can still install the Samba server on top of ZFS, and it wouldn't care. However, if you want ZFS to act as a pseudo-SambaServer (and dole out datasets as Samba shares), then yeah, you have a tricky situation on your hands. The difficulty stems from how ZFS datasets are even created, what's included and what's not. You might find this thread useful - I started it, actually.
 
I keep feeling you are not answering to my posts but to something else.

Btw: Ever ran Samba on FreeBSD?
 
I just explained why sharesmb is not really working on ZFS, and pointed to workarounds that achieve similar results.

Also - Yeah, I did run Samba on FreeBSD/ZFS... used WebMin to configure shares, and fished out a few files from /usr/home that way. You can easily tell Samba to set up shares in ways that correspond to the ZFS datasets. I think there's a Samba user on FreeBSD. It is quite possible to have a mismatch between the dataset ACL's that ZFS maintains and the permissions that a Windows client brings with them when asking for files.
 
Short version (yes, I run samba-on-zfs and smb-on-solaris for more than a decade on hundreds of servers)

1) samba CAN run on zfs. Mixing ACLs with zfs is not really smart (aka: hard and prone to error)
2) samba CAN run on zfs, with transparent "previous version" (for windows client) getted from snapshots
3) I confirm: no solaris-ACL style on samba-on-zfs for freebsd
4) It is possible to make a "fake" Windows workgroup fileserver server with freebsd, samba on zfs, changing the permissions "the Windows" way (aka: from a Windows client). Not very easy, but doable
5) It is possible to make a freebsd-samba-zfs fileserver, client of a Linux-based SMB domain (aka: a PDC-NT style)
6) It is possible to make an "all-in-one" FreeBSD samba PDC with zfs and everything, BUT it is not very handy (the big problem is lack of a (easy) GUI to create the users)
7) AFAIK it is NOT possible to make a Solaris PDC, unless a Samba one
 
Fully agree. I have 1.), 2.), 4.) and partially 5.)* running here. The topic was, wheter Samba operates on datasets and needs dataset permissions, which I understands it doesn't. It operates on folders within datasets, slices and partitions.

*Partially 5) meaning I run a fake Windows Domain server with Snapshots as previous versions, Trashbin etc. but I run 2 additional machines as redundant DC's on FreeBSD (!) but with UFS since it's troublesome to let the DC use ZFS. No Solaris experience, yet. But winter's coming ;-) Maybe I'll build my backup server on Solaris.

User creation isn't an issue, here, since it's a hobby project with only a handful of users.

But what do you mean with 3.) - Solaris style ACLs? I do use NFSv4 ACL's not Posix ones, which is a prerequisite for 4.) One needs to employ the appropriate vfs object but it's working after some fiddling. My topic was, that the "trivial" ACL's don't seem to have an effect on Samba, I need to set a separate entry per setfacl / Windows client.
 
Back
Top