After upgrading to macOS 10.15 I've hit an issue where if the share's
connection is interrupted for long enough (e.g. because the server is rebooted)
then the client Mac's Finder becomes stuck and?puts up a message 'The
operation can?t be completed because the original item for ?<share>? can?t
be found. Sometimes restarting Finder helps, sometimes restarting sharingd helps
but sometimes nothing helps. Older versions of macOS (e.g. 10.14) didn't
have this issue. At any rate I don't think there's anything Samba can do
about that issue...
However, I have noticed that when macOS is connected to another macOS served SMB
share it receives a notification that the share is going down that it displays
to the user. Is this done via the SMB connection or is it some out of band
thing?
Over
on?https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X?there
are a list of suggested options. Is having catia in "vfs objects"
definitely needed for good macOS compatibility or does it just depend on whether
you are running a Mac?program that creates an awkward filename? That page also
recommends having?streams_xattr in?"vfs objects" but the vfs_fruit man
page warns "Warning:?this option should not be used with
the?streams_xattr?module due to the extended attributes size limitations of most
filesytems.". In 99% of cases is the low limit on Linux filesystem like
ext4 (i.e. not? Btrfs, XFS, ZFS) not an issue?
Over
on?https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html?there's?fruit:metadata
= stream. Is this strictly better than having it set to =?netatalk? I've got
a share that used to be used with netatalk but it no longer is and I gather the
xattrs can't be converted...
Finally out of curiosity, is Samba's extended macOS compatibility achieved
with help from Apple and its source code or is it mostly reverse engineered?
