Understanding the Root Cause
The error xattr(22) failed: Invalid argument indicates that rsync tried to set an extended attribute on the destination file but received an invalid argument from the kernel. Extended attributes (xattrs) allow storing metadata alongside files, such as ACLs, SELinux contexts, or ZFS-specific properties. TrueNAS Core and Scale use ZFS, which supports rich xattrs. Debian servers typically use ext4 or XFS, which have different xattr limitations. When rsync transfers data via SSH, it attempts to preserve these attributes by default. If the destination cannot accept them, the transfer fails.
Solution 1: Disable Extended Attribute Transfer
The most reliable fix for this specific scenario is to tell rsync to ignore extended attributes during the backup. Since your goal is likely data backup rather than exact filesystem replication, ignoring xattrs is safe and prevents the error. Use the --no-xattrs flag in your rsync command.
rsync -av --no-xattrs -e ssh /path/to/source/ root@debian-server:/path/to/destination/This flag explicitly disables the copying of extended attributes. It ensures that only file contents, permissions, ownership, and timestamps are transferred. This approach resolves the immediate error without requiring changes to the destination server's configuration. It is particularly effective when migrating from ZFS to non-ZFS systems.
Solution 2: Check Destination Filesystem Support
If you must preserve extended attributes, verify that your Debian server's filesystem supports them. Most modern ext4 and XFS partitions support xattrs, but they may be configured differently. Ensure that the mount options on the Debian server include user_xattr. You can check current mount options using the mount command.
mount | grep /path/to/destinationIf user_xattr is missing, remount the filesystem with this option. However, note that even with support, ZFS-specific xattrs may still cause issues due to format incompatibility. In most backup scenarios, disabling xattrs is preferable to fighting filesystem differences.
Solution 3: Adjust Rsync Flags for Compatibility
Beyond --no-xattrs, consider other flags that improve compatibility between TrueNAS and Debian. The -A flag preserves ACLs, which might also fail if the destination doesn't support POSIX ACLs properly. If you encounter ACL errors after fixing xattrs, add --no-acls.
rsync -av --no-xattrs --no-acls -e ssh /source/ root@dest:/dest/Additionally, ensure you are using the latest version of rsync on both ends. Older versions may have bugs related to xattr handling over SSH. Update rsync on your Debian server using apt update && apt upgrade rsync. This ensures you benefit from recent bug fixes and improved protocol support.
Preventive Measures for Future Backups
To avoid similar issues in the future, standardize your rsync commands across all backups. Create a wrapper script that includes --no-xattrs and --no-acls by default for cross-platform backups. This ensures consistency and prevents unexpected failures. Document these flags in your backup documentation so that team members understand why certain attributes are excluded.
Regularly test your backup integrity using tools like diff or checksums to verify that data was transferred correctly despite excluding xattrs. This confirms that the core data remains intact and the backup is usable for recovery purposes.
Frequently Asked Questions
Can I recover lost extended attributes after migration?
No, once files are migrated without xattrs, those attributes cannot be recovered from the destination. You would need to re-run the backup with --xattrs enabled if the destination supports them, but ZFS-specific xattrs often remain incompatible. Consider documenting important xattrs separately if they are critical for application functionality.
Does disabling xattrs affect file permissions?
No, the --no-xattrs flag only affects extended attributes, not standard Unix permissions like read/write/execute. File ownership and basic permission bits are still preserved unless you explicitly disable them with --no-perms or --no-owner. Standard backup integrity remains unaffected.
Why does TrueNAS use different xattrs than Debian?
TrueNAS uses ZFS, which stores extended attributes in a special dataset property called xattr=sa or xattr=posix. These formats are optimized for ZFS internals and are not directly compatible with Linux's VFS xattr layer used by ext4/XFS. This architectural difference causes the "Invalid argument" error when rsync tries to translate them.
Is there a way to convert ZFS xattrs to Linux xattrs?
There is no direct conversion tool because ZFS xattrs often contain proprietary or ZFS-specific metadata. You can attempt to strip them using --no-xattrs during transfer, which is the recommended approach. Forcing conversion may result in data loss or corruption, so exclusion is safer for general backups.
How do I verify if my Debian server supports user_xattr?
Run getfattr -d -m - . in a directory on the destination. If it returns attribute values, xattrs are supported. If it fails with "Operation not supported," your filesystem lacks user_xattr mount option. Remount with remount,user_xattr to enable support.