Unable to copy certain files from Windows to FreeNAS

[Joseph Miller]

My FreeNAS server is set up and connected to my Windows domain. I'm copying files from the old Windows 2003 server, and most of the files copy without a problem. However, there are certain files (PSD files) which cannot be copied to FreeNAS no matter what permissions I set. Other files in the same source and destination folders can be copied without any problems. I've followed the instructions from standard guides, and I just can't figure it out. I continue to receive "Access Denied" error messages. Here's what I've tried.

List of what doesn't work:

• Removing all permissions from source file, changing ownership, adding explicit permissions
• Resetting permissions on the destination
• Creating a fresh dataset, setting full control permissions for everyone
• copy, xcopy, robocopy /b

List of what does work:

• Copying the file to a FAT filesystem, then copying to FreeNAS
• Right-click, Properties, Details, then Remove Properties and Personal Information (now the file will copy)

What the heck? I thought the Properties and Personal Information was only info within the file, not filesystem data. Something is very strange about this.

 

[anodos]

PSD files typically have metadata stored as 'alternate datastreams' (ADS). Make sure you have the 'streams_xattr' vfs object enabled for your share.

 

[Joseph Miller]

anodos, thanks for the reply. I already have streams_xattr enabled. This is very weird.

 

[anodos]

anodos, thanks for the reply. I already have streams_xattr enabled. This is very weird.

It's not that weird. Assuming that the problem is related to ADS, there is an upper-bound to how large you can make an xattr in FreeBSD. It's possible that the size of the ADS exceeds that value, which is a known problem. Check the contents of /var/log/messages and /var/log/samba4/log.smbd.

For testing purposes, create a new share that doesn't have streams_xattr enabled.

I'm not sure if the ability for a server to handle ADS is determined by the first tcon and used for all the remaining session (such as SMB2 AAPL extensions), or if it's re-negotiated with each connection to a share. For this reason, it might be good to disable streams_xattr on all shares, then restart the SMB service, then log out and log back in to the windows client (so that it will establish a fresh connection to the server).

My working theory regarding the above steps is that Windows will recognize the filesystem underlying the share as one that is unable to support ADS and therefore strip them as it writes to the share (like it does when writing to a FAT volume).

On the other hand, if you need to preserve this metadata you can try enabling the "streams_depot" VFS module. This will store the ADS to the filesystem in a hidden directory as opposed to an XATTR and therefore not suffer the same size constraints. Note that streams_depot is marked as "experimental". There are several problems with streams_depot as it currently is. For instance, the linkage between the ADS and the original file is based on the inode of the original file, which precludes manipulating files outside of samba (for fear of breaking the linkage). It also may limit the options you have regarding backup and restore software. ZFS replication is probably fine, but rsync may not work properly for preserving the metadata.

Also, it is worth mentioning that "streams_xattr" is required for "vfs_fruit".

 

[Joseph Miller]

Removing the streams_xattr fixed the problem. I can't think of any reason why I need the extra streams. I really just need the data in the PSD file. Thank you for figuring this out!

 

[anodos]

Removing the streams_xattr fixed the problem. I can't think of any reason why I need the extra streams. I really just need the data in the PSD file. Thank you for figuring this out!

No problem.