Bug 11673 - vfs_fruit problem when moving file between two ZFS filesystems within same share
Summary: vfs_fruit problem when moving file between two ZFS filesystems within same share
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 4.3.4
Hardware: x64 Solaris
: P5 normal (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: Samba QA Contact
Depends on:
Reported: 2016-01-14 15:47 UTC by Thomas Werschlein
Modified: 2020-02-12 20:18 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Werschlein 2016-01-14 15:47:15 UTC
OS platform: Solaris 11.1
Filesystem: ZFS
Samba version: 4.3.4


Given this share configuration:

  writable = yes
  path = /rpool/myshare
  vfs objects = fruit streams_xattr

and the following filesystem layout:

# zfs list -r rpool/myshare
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)

  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.
Comment 1 Björn Jacke 2020-01-03 10:52:28 UTC
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?
Comment 2 Thomas Werschlein 2020-02-12 14:34:14 UTC
(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.
Comment 3 Björn Jacke 2020-02-12 20:18:43 UTC
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?