OS platform: Solaris 11.1 Filesystem: ZFS Samba version: 4.3.4 Problem: Given this share configuration: [myshare] writable = yes path = /rpool/myshare vfs objects = fruit streams_xattr and the following filesystem layout: # zfs list -r rpool/myshare NAME USED AVAIL REFER MOUNTPOINT rpool/myshare 3.41G 55.1G 33K /rpool/myshare rpool/myshare/fs1 3.41G 55.1G 3.41G /rpool/myshare/fs1 rpool/myshare/fs2 49K 55.1G 49K /rpool/myshare/fs2 Note: fs1 and fs2 are ZFS filesystems, not directories. When moving "myfile" from myshare/fs1 to myshare/fs2 on a Windows SMB client (Server 2012 R2 or Windows 10) by "drag & drop", the file "myfile" disappears at the source location, quickly pops up at the target location and disappears there, too. In fact, nothing gets copied or moved, a refresh (F5) of the source directory window (myshare/fs1) makes "myfile" reappear. When doing this with a whole directory structure, the directories get copied (not moved), but not the files within them. This makes it confusing, since you get the impression, that the move did actually work, while it did not. Moving myshare/fs1/myfile to myshare/fs2/myfile by "drag & drop" with a share config like this (i.e. without vfs_fruit) [myshare] writable = yes path = /rpool/myshare vfs objects = DOES work (performing a server-side move, which is actually a server-side copy & unlink since two filesystems are involved). This leads me to the assumption that the combination of vfs_fruit and ZFS is the problem.
does this still happen these days with a more up-to-date version of Samba? If it still happens, can you try out enabling the vfs module crossrename in addition to the fruit config also?
(In reply to Björn Jacke from comment #1) We don't have any Solaris file servers anymore. Our ZFS storage is running on FreeBSD now. But I can confirm, that the reported problem does NOT manifest with Samba 4.10.11 running on FreeBSD 11.3. Moving files and directories between ZFS filesystems with vfs_fruit enabled works just fine.
I saw a problem similar to the one you described with vfs fruit when there was a *share* acl which allowed only *modify* permissions for the connected user but not *full* share access permissions. Might that have been the issue in your previous setup? Can you cross-check if such a change of the share acl would cause issues for your current setup again?