Mac client to SMB share - locked files / force eject

[vom]

I didn't want to necrobump - so I'm making this thread. But basically my question is the same as this thread:

https://www.ixsystems.com/community/threads/os-x-not-releasing-locks-on-samba-share.58967/

I've been trying to get my setup using more "modern" formats and protocols. Namely - moving from writing my backups as a sparseimage to a sparsebundle. Also working on moving from AFP sharing to SMB. I've been working on this all day - and it's working (with problems). I do want to say thanks to @anodos for helping me out this morning in another thread.

Anyway - the crux of my problem now is what appears to be file locking issues. With a sparsebundle format, the image is split into many smaller files called "bands". After I run my backup (I use Carbon Copy Cloner) - I still see "locked" files on FreeNAS (I'm running smbstatus to see this). I've tried some of the suggestions in that thread from 2017, but I still have the issue. I can recreate the issue by browsing to the share, mounting the sparsebundle, poking around, unmounting the sparsebundle and finally unmounting/disconnecting the SMB share in Finder. This is where the problem occurs as Finder will pop a warning that files are in use and present me with the option to "Force eject" - which I reluctantly do.

Is there any new information or solutions for this ? I'm really trying to get with the times and move away from AFP - but man - having something that works without all of these issues is pretty temping to fall back on. AFP is a hell of a drug for me :)

Also relevant versions: Freenas 11.2-U2.1, macOS 10.14.3 (latest)

Thanks in advance for any pointers.

EDIT: Just found this: https://redmine.ixsystems.com/issues/5904

I don't pretend to understand everything there. But from what I can gather the vfs_fruit module will "fix some mac quirks". Looks like that is slated to come in with some 11.3 version of FreeNAS. Is this something I could try now ? If so - how ? I don't want to blindly add these vfs parameters to the config.

 

[vom]

So I took some time this morning to make a test SMB share and tried the vfs modules and parameters from https://redmine.ixsystems.com/issues/5904

Doing a CCC backup to a sparsebundle seemed to work just fine, and I could see file access in smbstatus When it was complete, there weren't stale files open/locked and I was able to cleanly unmount the share from Finder.

What I did was add the vfs modules and parameters from that ticket, but I also left the defaults that were already there from FreeNAS. So my smb4.conf stanza for this test share looks like this:

Code:

[backup-smb]
    path = "/mnt/bigdisk/backup-smb"
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    access based share enum = no
    fruit:metadata = stream
    fruit:resource = stream
    vfs objects = catia zfs_space zfsacl fruit streams_xattr
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare
    fruit:resource = xattr
    fruit:metadata = netatalk
    fruit:locking = netatalk
    fruit:encoding = private

I'd like to know the extent to which these options would be automatically set in Freenas 11.3+. I'm not quite understanding what's being said in that ticket. I'm reading it as AFP / SMB co-existence ? My question is more how/when/why would these options be populated automatically ? Will there be some "Enable Mac client fixes" checkbox that will do this perhaps ?

 

[anodos]

fruit:resource shouldn't be set to `xattr`

Code:

static int ad_open_rsrc_xattr(const struct smb_filename *smb_fname,
                int flags,
                mode_t mode)
{
#ifdef HAVE_ATTROPEN
    /* FIXME: direct Solaris xattr syscall */
    return attropen(smb_fname->base_name,
            AFPRESOURCE_EA_NETATALK, flags, mode);
#else
    errno = ENOSYS;
    return -1;
#endif
}

Since we don't have the Solaris syscall, we immediately return -1 (fail), and your MacOS client will fail to write the Resource Fork (which might be a bad thing).

locking:netatalk
This one allows cross-protocol file locking with netatalk. The default is 'none'.

catia and fruit:encoding = private
are nice convenience features. Apple uses invalid ntfs characters in some xattr names (and allows them as file names). The MacOS SMB client translates these to characters in the unicode private range before sending across the wire. They're technically valid, but are a pain to manipulate from shell. I'd like to change the settings, but if I do, people will potentially lose access to AFP resources on already-written data. I might expose as a checkbox for `enhanced MacOS support`.

fruit:metadata = netatalk
This one means that you're choosing to write the AFP_AfpInfo stream to a ._file rather than a filesystem xattr (fruit:metatadata=stream). We opt by default to write to an xattr through streams_xattr because it avoids having the filesystem littered with appledouble files. This is a useful test to narrow down the new file locking issues (something I plan to investigate next week).

The problems I've seen in the past are related to MacOS behavior related to locking resource forks (AFP_Resource). When opened in Preview, the MacOS SMB client will set a SMB2 RH lease on the AFP_Resource and never close / release it (this will be visible in smbstatus output). You can mitigate the issue by turning off SMB2 leases entirely in this case. You probably stopped seeing the issue because your settings prevent writing AFP_Resource xattrs, but there is potentially a regression in fruit's handling of AFP_AfpInfo on streams that I'll have to look at.