Alternate Data Streams (ADS) with Fruit on SMB share problem
I can't seem to succesfully copy a folder with ADS to FreeNas when the "fruit" module is enabled.
It is a SMB share used by both Windows and Mac device.
If I enable the following module, everything works :
If I enable "fruit", I have problem copying files.
But if I enable also "streams_depot", everything works again.
So this works :
This don't works :
But this works :
The problem I have copying the folder is :
- Error 0x80070032: The request is not supported
Using "streams.exe" from "SysInternals" to delete ADS from source folder fix the problems but I should not have to do that.
#1 Updated by Dru Lavigne over 2 years ago
- Assignee changed from Release Council to Timur Bakeyev
- Target version set to 11.2-RC2
- Private changed from No to Yes
- Reason for Blocked set to Need additional information
Jean-Philippe: please attach a debug (System -> Advanced -> Save Debug) to this ticket.
#4 Updated by Andrew Walker over 2 years ago
streams_depot should not be used in production.
Please do the following:
1) set only the following VFS modules: zfs_space, zfsacl, fruit, streams_xattr
2) restart the samba service
3) unmount all shares from your OSX client
4) remount share and try to copy again.
If the problem persists after doing (1)-(4), increase logging to "debug" under services->smb, reproduce the problem, the upload a new debug file.
#5 Updated by Jean-Philippe Laguë over 2 years ago
- File debug-freenas-20180326160509.tgz added
Fist, we have about 80% Windows and 20% MacOS that access the same share.
The copy problem is only with Windows client, not Mac OS client.
The data source is from a NetApp (CIFS share) that we migrate to FreeNas.
With the following module enabled, the Windows copy fails :
- zfs_space, zfsacl, fruit, streams_xattr
With the following module, it works :
- zfs_space, zfsacl, fruit, streams_xattr, streams_depot, catia
If I remove "fruit", it works.
See hte debug log for more informations.
Since my users need to continu copying data, I let the streams_depot module enable for now.
#17 Updated by Timur Bakeyev over 2 years ago
Thanks for the log level 10 debug log, it's way more helpful. Still, the smb4.conf that came with it shows that you are using
[test] path = "/mnt/tank/test" printable = no veto files = /.snapshot/.windows/.mac/.zfs/ writeable = yes browseable = yes access based share enum = no vfs objects = zfs_space zfsacl streams_depot catia fruit streams_xattr hide dot files = yes guest ok = no nfs4:mode = special nfs4:acedup = merge nfs4:chown = true zfsacl:acesort = dontcare
Which just defeats whole idea of exposing the problem you experience. I'm not sure, does your log corresponds to the given configuration or to the problematic one.
On a side note one of the configuration parameters you put in the share definition causes:
Global parameter client ipc signing found in service section!
#18 Updated by Timur Bakeyev over 2 years ago
As we recently fixed a bug in the
vfs_streams_xattr which was caused by the combination of MacOSX 11.3(?) handling of AFP_Info streams and by a bug in the VFS module itself, I've checked the provided log against this bug also.
[2018/03/26 16:03:35.411289, 10, pid=8066, effective(1002, 1007), real(0, 0), class=fruit] ../source3/modules/vfs_fruit.c:3967(fruit_pwrite)
fruit_pwrite: Path [TESTS_JP_LAGUE/Audio:AFP_AfpInfo] offset=0, size=60
[2018/03/26 16:03:35.411297, 1, pid=8066, effective(1002, 1007), real(0, 0), class=fruit] ../source3/modules/vfs_fruit.c:1682(afpinfo_unpack)
Bad AfpInfo signature or version
[2018/03/26 16:03:35.411303, 10, pid=8066, effective(1002, 1007), real(0, 0), class=fruit] ../source3/modules/vfs_fruit.c:3979(fruit_pwrite)
fruit_pwrite: Path [TESTS_JP_LAGUE/Audio:AFP_AfpInfo] nwritten=-1
[2018/03/26 16:03:35.411309, 10, pid=8066, effective(1002, 1007), real(0, 0)] ../source3/smbd/fileio.c:132(real_write_file)
real_write_file (TESTS_JP_LAGUE/Audio:AFP_AfpInfo): pos = 0, size = 60, returned -1
[2018/03/26 16:03:35.411317, 2, pid=8066, effective(1002, 1007), real(0, 0)] ../source3/smbd/smb2_write.c:201(smb2_write_complete_internal)
smb2_write failed: fnum 2950449010, file TESTS_JP_LAGUE/Audio:AFP_AfpInfo, length=60 offset=0 nwritten=-1: NT_STATUS_NOT_SUPPORTED
[2018/03/26 16:03:35.411326, 10, pid=8066, effective(1002, 1007), real(0, 0)] ../source3/smbd/smb2_write.c:377(smbd_smb2_write_send)
smb2: write on file TESTS_JP_LAGUE/Audio:AFP_AfpInfo, offset 0, requested 60, written = 4294967295
[2018/03/26 16:03:35.411335, 3, pid=8066, effective(1002, 1007), real(0, 0)] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx1 status[NT_STATUS_NOT_SUPPORTED] || at ../source3/smbd/smb2_write.c:135
You, apparently, also was affected by it and, it seems, your problems were caused by it's exposure.
That bug was fixed in the upcoming 11.1-U6 and in the 11.2-beta1(released). So, it's worth trying to see if your problems are gone.
Please note, that the fix also affected the way, how streams are stored on disk, so it's necessary to run a utility
fix_ea after installing new version. The details should be in the release docs.