Bug 13175 - Accessing ZFS snapshot directories over SMB
Accessing ZFS snapshot directories over SMB
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules
All All
: P5 normal
: ---
Assigned To: Ralph Böhme
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2017-12-05 09:24 UTC by Ralph Böhme
Modified: 2018-02-28 23:22 UTC (History)
6 users (show)

See Also:

WIP patch for master (1.73 KB, patch)
2017-12-05 09:24 UTC, Ralph Böhme
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2017-12-05 09:24:24 UTC
Created attachment 13845 [details]
WIP patch for master

Currently trying to access ZFS snapshot directories over SMB fails:

$ bin/smbclient -U slow%x //localhost/test
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Tue Dec  5 09:05:27 2017
  ..                                  D        0  Tue Dec  5 08:49:27 2017
  .zfs                               DH        0  Tue Dec  5 08:49:27 2017
  test                                D        0  Tue Dec  5 09:06:06 2017

                1949611 blocks of size 1024. 1949578 blocks available
smb: \> ls .zfs/*

This happens because the acl() library call fails with ENOTSUP on the snapshot directories. This could be easily fixed by synthesizing an ACL based on the POSIX mode, much like the getfacl() command on FreeBSD does. The attached WIP patch implements this.

Question do we want this?
Comment 1 Jeremy Allison 2017-12-05 17:10:32 UTC
Yes we do (so long as it doesn't open up security). ZFS-based filers are very popular, and so long as Linux doesn't have RichACLs this is the only game in town. So +1 from me ! (Jeremy).
Comment 2 Timur Bakeyev 2017-12-07 05:18:44 UTC
Thanks, Ralph, we are going to look. We have related problem with the snapshots and extended attributes, could be that it lays here in fact.
Comment 3 Ralph Böhme 2017-12-07 13:28:11 UTC
(In reply to Timur Bakeyev from comment #2)
Thanks Timur! Btw, I actually built and tested the patch this time. :)
Comment 4 Ralph Böhme 2018-02-10 08:03:08 UTC
Timur, any chance for an update from your side? Afaict my patch is correct and Jeremy ACKed as well so we could push this upstream.
Comment 5 Timur Bakeyev 2018-02-17 04:36:06 UTC
(In reply to Ralph Böhme from comment #4)

Hi, Ralph!

Sorry for the delay with the answer, seems I mis-configured my Gmail filters, so updates on the Bugzilla silently ended up in the folder.

It seems this issue attracted quite an attention 

There is a patch for ZFS at least for FreeBSD, that should eliminate the said error in the future versions of the OS:


My colleague Andrew Walker also made his own patch, similar in principal to yours, to address the same issue:


His patch somewhat similar to the call to make_default_filesystem_acl(DEFAULT_ACL_EVERYONE) with the exception that also owner and group ACEs are set. Also it's handy that there is a configuration option that allows to enable and disable this feature.

Originally this patch was even more sophisticated as it tried to convert mode bits into corresponding NFSv4 ACEs:

Comment 6 Timur Bakeyev 2018-02-17 05:09:30 UTC
(In reply to Timur Bakeyev from comment #5)

I would suggest to take ZFS in-kernel implementation as a sample for emulation on zfsacl level. In the perfect world we wouldn't need any emulation, as ZFS(at least on FreeBSD) would perfectly handle the situation by itself, but there still be old versions of FreeBSD, ZFS on Linux and Illumos.

So, we have:

/* Common access mode for all virtual directories under the ctldir */
const u_short zfsctl_ctldir_mode = S_IRUSR | S_IXUSR | S_IRGRP | S_IXGRP |

aka 0555.

This is translated to NFSv4 ACL with some cleanups:

777 	int
778 	zfsctl_common_getacl(ap)
779 	        struct vop_getacl_args /* {
780 	                struct vnode *vp;
781 	                acl_type_t a_type;
782 	                struct acl *a_aclp;
783 	                struct ucred *cred;
784 	                struct thread *td;
785 	        } */ *ap;
786 	{
787 	        int i;
789 	        if (ap->a_type != ACL_TYPE_NFS4)
790 	                return (EINVAL);
792 	        acl_nfs4_sync_acl_from_mode(ap->a_aclp, zfsctl_ctldir_mode, 0);
793 	        /*
794 	         * acl_nfs4_sync_acl_from_mode assumes that the owner can always modify
795 	         * attributes.  That is not the case for the ctldir, so we must clear
796 	         * those bits.  We also must clear ACL_READ_NAMED_ATTRS, because xattrs
797 	         * aren't supported by the ctldir.
798 	         */
799 	        for (i = 0; i < ap->a_aclp->acl_cnt; i++) {
800 	                struct acl_entry *entry;
801 	                entry = &(ap->a_aclp->acl_entry[i]);
802 	                uint32_t old_perm = entry->ae_perm;
803 	                entry->ae_perm &= ~(ACL_WRITE_ACL | ACL_WRITE_OWNER |
805 	                    ACL_READ_NAMED_ATTRS );
806 	        }
808 	        return (0);
809 	}

I can imagine a separate ACL type option for the `make_default_filesystem_acl()` that would generate such a special NFSv4 ACL or, which is possibly cleaner, take Andrew's approach and implement creation of such an ACL in the `zfsacl` module itself, as it's quite specific to it.

What I miss in both implementations is the check that we are actually dealing with `.zfs/` or `.zfs/snapshot` or `.zfs/shares` directories. Not sure how critical is this. I can imagine some weird mounts of NFS or UFS file systems into ZFS share that possibly can give similar ENOSYS error.
Comment 8 Jeremy Allison 2018-02-20 19:14:03 UTC
What is the state of this one ? Seems to have stalled, and I want to make sure we fully enable ZFS ACLs as a 'first class' citizen in Samba ?
Comment 9 Timur Bakeyev 2018-02-22 02:32:22 UTC
(In reply to Jeremy Allison from comment #8)
We'd love to see ZFSACL as a first class citizen as well. Or, maybe, NFSv4 in general next to POSIX, like FreeBSD does.

I've left in the comments how we'd like to see this feature to be implemented in the ZFSACL module, so next question who and how is going to implement it. I'd again suggest to join the approaches and implement emulation of the FreeBSD ZFS behavior regarding .zfs directories in the ZFSACL itself, using mocked up NFSv4 ACLs.

Not sure now about the need of the configuration switch here, as in some versions of FreeBSD we'll get those NVSv4 ACLs naturally from the OS itself without any switch, so we can only try to transparently emulate OS in the case we are on an older system.

That shouldn't affect ZFS on Linux as so far they still don't have NFSv4 ACLs, hence ZFSACL module isn't applicable.

So, the question is who is going to write the code? We can do this, but also Ralph seems interested in it. What would be your advise?
Comment 10 Ralph Böhme 2018-02-22 09:08:14 UTC
(In reply to Timur Bakeyev from comment #9)
Timur, if you have the resources, go for it. :)
Comment 11 Timur Bakeyev 2018-02-27 02:42:57 UTC
(In reply to Ralph Böhme from comment #10)
Not much, but I'll prepare yet another WIP, so we can discuss it farther :)
Comment 12 Ted Cabeen 2018-02-28 22:49:02 UTC
It would also be useful to ensure this works when using vfs_acl_xattr with acl_xattr:ignore system acls = yes.  In this case, Samba has full control of the ACLs, but ZFS snapshot directories are still inaccessible (getfattr -n security.NTACL .zfs returns "Operation not supported"), and mapping the ZFS snapshots into Windows Volume Shadow Copies via vfs_shadow_copy2 also fails.
Comment 13 Timur Bakeyev 2018-02-28 23:03:26 UTC
(In reply to Ted Cabeen from comment #12)

Ted, can you specify what system/OS are you referring to and what is your setup then, that uses vfs_acl_xattr?

So far we were talking about vfs_zfsacl, mostly applicable to FreeBSD(as Solaris is half-way dead and has it's own SMB implementation AFAIK).
Comment 14 Ted Cabeen 2018-02-28 23:22:10 UTC
This is on CentOS 7.4 with the ZFS on Linux modules.  In my case, I'm not using ZFS or Unix ACLs at all.  The filesystems in question are only accessed by Samba, and the POSIX mode and owner/group are largely unused.  I was concerned that a solution would be developed that mocked up ACLs from POSIX data that's unused in this scenario.

I did open an issue with the ZoL group, as I think it might make more sense to just fix this at the ZFS layer, by returning the ACL/xattrs of the ZFS filesystem  mountpoint when accessing ACLs or xattrs on the .zfs and .zfs/snapshot directories: https://github.com/zfsonlinux/zfs/issues/7253