Rafaqs

I already bought two 16GB Optane drives (US$5) with USB cases :) And with this RAM shortage on the market, their prices might go up.

Hi @bmartino1 I wanted to stop by and personally thank you for your incredible breakdown of the SMB/Samba issues with macOS Tahoe. Your insight regarding the regression in SMB 4.21.x combined with Tahoe's new parallel SMB CREATE requests and durable handles was the 'missing link' for me. It perfectly explains why my native Unraid SMB shares were failing instantly with the 'could not create backup image' error, while the Docker-based Samba solution (mbentley/timemachine) worked flawlessly. I’ve spent the last 24 hours troubleshooting this across multiple NAS units (XFS and ZFS), and your post confirmed my suspicion: the issue lies within Unraid’s specific Samba integration layer and how it handles ACL coercion and metadata negotiation, rather than the underlying filesystem or basic permissions. The ZFS optimization tips you provided (xattr=sa, dnodesize=auto, and acltype=posixacl) are gold. I am currently running a 60GB+ backup for a second MacBook on a ZFS dataset via Docker, and I plan to use your suggested flags to optimize my permanent array next weekend. Your technical expertise has not only solved my immediate problem but is also helping me evolve my entire infrastructure into a more robust, 'future-proof' setup. Cheers from Brazil!

[SOLVED] Time Machine on Unraid 7.2.3 + macOS Tahoe: Native SMB failures vs. Docker SuccessHi everyone, After 8+ hours of troubleshooting a "The backup disk image could not be created" error on my M3 Max MacBook Pro (macOS Tahoe 26.2), I wanted to share the findings that finally got my backups running at 10Gb speeds. My Setup: Unraid: 7.2.3 (Samba 4.21.3) Client: MacBook Pro M3 Max (macOS Tahoe 26.2) Network: 10Gb SFP+ (Unifi infrastructure) Hardware: i5, 64GB RAM. What DID NOT work (Native SMB): ZFS Pools: Even with vfs_fruit and Enhanced macOS interoperability enabled, the backup failed during the "Creating disk image" phase. XFS Dedicated Disks: I formatted a dedicated 6TB XFS drive to test if ZFS was the culprit. It still failed. The native SMB service in Unraid 7.2.3 seems to have a metadata handshake issue with the latest macOS version that causes immediate timeouts. The Solution: Time Machine via Docker The only 100% stable solution was bypassing the Unraid native SMB service and using the timemachine-samba Docker container (mbentley/awlx). This worked perfectly on both my NAS units: NAS 1: Running on XFS. NAS 2: Running on ZFS. Crucial Steps for 10Gb Stability: Hardware Fix (Syslinux): For 10Gb cards, I had to add pcie_aspm=off pci=noaer to the Syslinux configuration to prevent PCIe bus errors and log spamming during heavy transfers. Dedicated IP (Custom br0): Assign a unique IP to the Docker container (e.g., .220). This prevents port 445 conflicts with the Unraid host and provides a "clean" Avahi/mDNS broadcast for the Mac. Container Path Alignment: This is vital. You must edit the Docker template so the Container Path matches your TM_USERNAME (e.g., /opt/youruser). If they don't match, the Docker will write data into the docker.img vDisk instead of your HD, filling your system disk in minutes. Permissions: Run chown -R 1000:1000 /mnt/user/your_share/ via terminal before starting the container to ensure the internal Docker user has write access. Conclusion: If you are on high-end hardware and the latest macOS, don't waste hours fighting with Native SMB Settings or SMB Extras. The Docker isolation provides the specific Samba environment the Mac expects, regardless of whether your backing store is XFS or ZFS. Hope this helps someone save a day of work!

Hello everyone, I’m reaching out to document and share a persistent issue regarding macOS Time Machine backups failing on Unraid 7.2.3 using ZFS pools. Despite a robust environment and extensive troubleshooting, the error "The backup disk image could not be created" persists. Environment: Server: Unraid 7.2.2 updated to 7.2.3. Networking: 10Gb SFP+ infrastructure (UniFi USW Aggregation). Clients and NAS connected via SFP+ modules. Clients: Multiple MacBooks running macOS Tahoe (26.1 and 26.2). Storage: ZFS pool on NAS 2 (previously worked flawlessly on NAS 1 using XFS). Troubleshooting Steps Taken: OS Updates: Both Unraid and macOS Tahoe were updated to the latest versions to rule out known Samba/Sequoia-era bugs. ZFS Dataset Tuning: Set xattr=sa and dnodesize=auto. Confirmed casesensitivity=sensitive. Manual SMB Configuration (SMB Extras): Created manual shares to bypass Unraid's default templates. Implemented force user = root to eliminate permission-level handshake issues. Tested various vfs objects and fruit parameters: metadata=stream, metadata=netatalk, locking=none, posix_rename=yes, etc. Hardware Stability: Identified PCIe Bus Errors (atlantic driver for the 10Gb NIC) in the syslog during Time Machine metadata stress tests. Applied pcie_aspm=off and pci=noaer in Syslinux. This stabilized the hardware (no more AER errors), but the Time Machine error remained. Cross-Testing: Tested with different MacBooks and different network interfaces (Thunderbolt SFP+ adapters and built-in NICs). Conclusion: The backup process consistently fails at the "Creating backup disk image" stage on ZFS. Given that the exact same setup (same network, same Macs) worked perfectly on an XFS-formatted NAS, there appears to be a specific protocol incompatibility between macOS Tahoe’s sparsebundle creation and the ZFS implementation in Unraid 7.2.3 when handled via SMB. I am moving back to XFS for stability, but I wanted to provide this log for the developers and the community. If anyone has found a definitive fix for Tahoe + ZFS, I’d love to hear it.