New share created after update to 7.2.3 - same error :-(

I cannot reproduce the issue. Please post the version you are using, the settings for TM, the share name, and the diagnostics.

I am too having problems: Time Machine fails with the message that it can't create the disk image.

Unraid Version 7.2.3 and macOS Tahoe 26.2

I have recreated the Unraid share and the time machine disk on the Mac, but still no joy

myserver-diagnostics-20251219-2328.zip

Edited December 19, 2025Dec 19 by kokni

9 hours ago, JorgeB said:

I cannot reproduce the issue. Please post the version you are using, the settings for TM, the share name, and the diagnostics.

Hi Jorge, restoring, making new share, and even reinstalling macos has had no effect. I am on macos 26.2.

As requested: Settings for TM share;

While TimeMachine is sitting on a ZFS pool, I thought I would try a share on the main array too, just to be sure and I get the same error message of 'The backup disk image could not be created'.

tower-diagnostics-20251220-1058.zip

Edited December 20, 2025Dec 20 by GMAsterAU

7 hours ago, GMAsterAU said:

I am on macos 26.2.

10 hours ago, kokni said:

Tahoe 26.2

When I can I'm going to update to 26.2 and retest to see if there's any difference, and if it still works for me, I'll see if I can find any difference in the diags/settings.

I've updated Tahoe to 26.2, still working for me, tried backing up to the array, to pools, xfs, zfs, no size limit, size limit, encrypted, not encrypted. I cannot get it to fail...

1 hour ago, JorgeB said:

I've updated Tahoe to 26.2, still working for me, tried backing up to the array, to pools, xfs, zfs, no size limit, size limit, encrypted, not encrypted. I cannot get it to fail...

For me it is also still not working when trying to creating a new backup on a new share. It also fails with the message that it can't create the disk image

(Also on macOS 26.2 and Unraid 7.2.3, Backup to a btrfs formatted SSD pool, without array mover).

For the sake of curiosity I wanted to narrow down the issue to either the Unraid side, or the Mac side.
Therefore, as a test, I used my raspberry pi as a backup target with the following docker container which contains Samba 4.22.6 already configured for the use with TimeMachine:

mbentley/timemachine:smb

```bash
docker run -d \

--name timemachine \

-p 137:137/udp \

-p 138:138/udp \

-p 139:139 \

-p 445:445 \

-e TM_USERNAME="timemachine" \

-e TM_GROUPNAME="timemachine" \

-e PASSWORD="timemachine" \

-e TM_UID="1000" \

-e TM_GID="1000" \

-e SET_PERMISSIONS="false" \

-e VOLUME_SIZE_LIMIT="0" \

-v $PWD:/opt/timemachine \

--tmpfs /run/samba \

mbentley/timemachine:smb
```

In this case the backup worked just fine without any issues.

So the issue must be either on Samba's side with the newer versions, or on Unraid's side.

@JorgeB Did you also test a new backup from scratch (e.g. with a new TM share), or did you only try incremental backups to a previous existing share?

Edited December 22, 2025Dec 22 by greenflash24

I'm having exact the same issue, also on Unraid 7.2.3 (Samba version 4.23.4) and Tahoe 26.2. I have also tested new backup from scratch, tried creating brand new share as well. No Luck. I see a following line item on macOS logs though. I have manually tested the permissions and they are setup correctly, I can read and write to the share.

2025-12-20 17:22:04.394086+0000  localhost SystemUIServer[8090]: (TimeMachine) [com.apple.TimeMachine:TMDisk] attrVolumeWithMountPoint 'file:///Volumes/.timemachine/Tower._smb._tcp.local/XXX-404A-4AC8-9720-XXXXXX/timemachine/' failed, error: Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"

Edited December 20, 2025Dec 20 by Lightman32

lattest 4 imac... mid 2025... No issues with time machine...

Its best to use smb extra parm and make your own time machine backup using the smb extra options...
Have and make a samba user in unriad web ui...
and let apple dictate the quota !!!

as explained here:

On 12/18/2025 at 8:00 PM, bmartino1 said:

...

https://forums.unraid.net/topic/178033-bmartino1-user-scripts/#findComment-1478661

smb extra... make your own time machine share...

#example Apple Time Machine (let apple define quota not unraid...)
[TimeMachine]
    path = /mnt/user/TimeMachine
    browseable = yes
    read only = no
    guest ok = no
    # time machien requires a samba user connected!
    valid users = samba_user root
    writeable = yes
    acl map full control = yes
    acl allow execute always = yes
    map archive = yes
    map system  = yes
    map hidden  = yes
    create mask        = 0660
    force create mode  = 0669
    directory mask     = 0770
    force directory mode = 0770
    force user  = root
    force group = root
    vfs objects = catia fruit streams_xattr
    fruit:encoding = native
    # If you want Unraid to advertise this as a Time Machine target:
    fruit:time machine = yes
    # If you want unraid asigned size quota
    ; fruit:time machine max size = 0
    fruit:metadata = stream
    fruit:resource = stream
    fruit:locking = none
    # ACL + extended attributes
    ea support = yes
    store dos attributes = yes

you must have a smaba user made inthe urnaid web ui and set valid users... then connect to TimeMachine as that users.. then one can use apple time machine on apple sied to set quota and connction via settings...

my recommendation instead of redoing the whole smb conf... (tested working)...

Steps manually create and control you own samba share...
First go to users:
make a dedicated user that will connect to your time machine share. This will be the apple connected user...

next pick a location where you want the share saved...

in my case that path is /mnt/user/TimeMachine

so we set and fix permission first...

cd /mnt/user/
chmod 777 -R TimeMachine

chown nobody:users -R TimeMachine

*This to make sure that unraid has correct permissions...
-For extra hardening you can set the user to the smb user you just made...

then stop the array... (as it the only way to apply and set stuff in smb extra...)
Setting > smb extras


and paste in the time machine share...
DO NOT REUSE A SHARE NAME IF IN THE SAHRES TAB!!!!

example time machine smb share for extra this will make a samba share called TimeMachine

[TimeMachine]

path = /mnt/user/TimeMachine

browseable = yes

read only = no

guest ok = no

writeable = yes

acl map full control = yes

acl allow execute always = yes

map archive = yes

map system = yes

map hidden = yes
vfs objects = catia fruit streams_xattr

fruit:encoding = native

fruit:metadata = stream

fruit:resource = stream

fruit:locking = none

ea support = yes

store dos attributes = yes

#Edit and set yourself!

# If you want Unraid to advertise this as a Time Machine target:

fruit:time machine = yes

; fruit:time machine max size = 0

# Restrict access to specific users the user you made in the web ui! REQUIRED BY TIME MACHINE!

valid users = apple samba

#as files are written to unraid share this forces the chmod of files on the share... 777 / 655 security to who can see read write...

create mask = 0660

force create mode = 0660

directory mask = 0770

force directory mode = 0770

#this force what every user that conected to be this user/group so all time machene files are writeen as unraid root... for extra hardning set to the chown user/groups...

force user = root

force group = root

start the array...
in termianl run testparm:

*I'm testing virtio / wemu 9pm moses in aunraid VM passing virtio to a folder in unraid... this is why my path says /host...
One could also do a fuse folder bind mount and move time machien to another folder...

example as I have another unraid baremetal elsewhere... and have a share set for just my main vm unraid... so nfs a folder..

/sbin/mount -t 'nfs' -o rw,hard,timeo=50,retrans=5,relatime,rsize=1048576,wsize=1048576 'BMM-TOWER:/mnt/user/Dockers' '/mnt/remotes/BMM-TOWER_Dockers'
mount --bind /mnt/remotes/BMM-TOWER_Dockers /nfs
mount --make-shared /nfs

*This will make the folders at one location another... (original was going to keep things nice by adding to the /mnt/folder but FCP complains to much...)
...

then resetup your time machine and when asked if reusing existing files/folder to yes reuse them!



time machine and samba is not "broke" just needs other samba stuff...
Be sure to save your unraid user in teh key chain and MAKE SURE YOUR SAMBA IS CONECTED AS THE UNRAID USER FOR APPLE TIMEMACHINE!!!

6 hours ago, bmartino1 said:

lattest 4 imac... mid 2025... No issues with time machine...

Its best to use smb extra parm and make your own time machine backup using the smb extra options...
Have and make a samba user in unriad web ui...
and let apple dictate the quota !!!

as explained here:

my recommendation instead of redoing the whole smb conf... (tested working)...

Steps manually create and control you own samba share...
First go to users:
make a dedicated user that will connect to your time machine share. This will be the apple connected user...

next pick a location where you want the share saved...

in my case that path is /mnt/user/TimeMachine

so we set and fix permission first...

cd /mnt/user/
chmod 777 -R TimeMachine

chown nobody:users -R TimeMachine

*This to make sure that unraid has correct permissions...
-For extra hardening you can set the user to the smb user you just made...

then stop the array... (as it the only way to apply and set stuff in smb extra...)
Setting > smb extras


and paste in the time machine share...
DO NOT REUSE A SHARE NAME IF IN THE SAHRES TAB!!!!

example time machine smb share for extra this will make a samba share called TimeMachine

[TimeMachine]

path = /mnt/user/TimeMachine

browseable = yes

read only = no

guest ok = no

writeable = yes

acl map full control = yes

acl allow execute always = yes

map archive = yes

map system = yes

map hidden = yes
vfs objects = catia fruit streams_xattr

fruit:encoding = native

fruit:metadata = stream

fruit:resource = stream

fruit:locking = none

ea support = yes

store dos attributes = yes

#Edit and set yourself!

# If you want Unraid to advertise this as a Time Machine target:

fruit:time machine = yes

; fruit:time machine max size = 0

# Restrict access to specific users the user you made in the web ui! REQUIRED BY TIME MACHINE!

valid users = apple samba

#as files are written to unraid share this forces the chmod of files on the share... 777 / 655 security to who can see read write...

create mask = 0660

force create mode = 0660

directory mask = 0770

force directory mode = 0770

#this force what every user that conected to be this user/group so all time machene files are writeen as unraid root... for extra hardning set to the chown user/groups...

force user = root

force group = root

start the array...
in termianl run testparm:

*I'm testing virtio / wemu 9pm moses in aunraid VM passing virtio to a folder in unraid... this is why my path says /host...
One could also do a fuse folder bind mount and move time machien to another folder...

example as I have another unraid baremetal elsewhere... and have a share set for just my main vm unraid... so nfs a folder..

/sbin/mount -t 'nfs' -o rw,hard,timeo=50,retrans=5,relatime,rsize=1048576,wsize=1048576 'BMM-TOWER:/mnt/user/Dockers' '/mnt/remotes/BMM-TOWER_Dockers'
mount --bind /mnt/remotes/BMM-TOWER_Dockers /nfs
mount --make-shared /nfs

*This will make the folders at one location another... (original was going to keep things nice by adding to the /mnt/folder but FCP complains to much...)
...

then resetup your time machine and when asked if reusing existing files/folder to yes reuse them!



time machine and samba is not "broke" just needs other samba stuff...
Be sure to save your unraid user in teh key chain and MAKE SURE YOUR SAMBA IS CONECTED AS THE UNRAID USER FOR APPLE TIMEMACHINE!!!

Thank you for trying to help with this, but unfortuantely it did not make a difference.

Here is my samba config:

[global]
fruit:aapl = yes
fruit:nfs_aces = no
fruit:copyfile = yes
multicast dns register = yes
ea support = yes
[TimeMachine]
path = /mnt/user/TimeMachine
browseable = yes
read only = no
guest ok = no
writeable = yes
acl map full control = yes
acl allow execute always = yes
map archive = yes
map system = yes
map hidden = yes
vfs objects = catia fruit streams_xattr
fruit:encoding = native
fruit:metadata = stream
fruit:resource = stream
fruit:locking = none
ea support = yes
store dos attributes = yes
fruit:time machine = yes
; fruit:time machine max size = 0
valid users = gabriel
create mask = 0660
force create mode = 0660
directory mask = 0770
force directory mode = 0770
force user = root
force group = root

testparm output:

[TimeMachine]
        create mask = 0660
        directory mask = 0770
        force create mode = 0660
        force directory mode = 0770
        force group = root
        force user = root
        include = /boot/config/smb-extra.conf
        map hidden = Yes
        map system = Yes
        path = /mnt/user/TimeMachine
        valid users = gabriel
        vfs objects = catia fruit streams_xattr
        write list = gabriel
        fruit:time machine max size = 5000000M
        fruit:time machine = yes
        fruit:metadata = stream
        fruit:encoding = native

Do you have any other suggestions?

I did also do a sanity check by creating a backup on a removable external drive, which worked without issues (however I have to note that it had to be formatted as APSF, as it refuces to work with HFS+).

I also read somewhere that the name of the mac can have an impact. Mine used to be 'Gabriel's MacBook Pro', so I changed it to 'MacBookPro_M4'. No effect.

I also captured the output from a newly created backup with sudo log stream --predicate 'subsystem == "com.apple.TimeMachine"' --info --style compact | tee tm_system_log.txt. Output is in the attached file

tm_system_log.txt

16 hours ago, greenflash24 said:

Did you also test a new backup from scratch (e.g. with a new TM share),

Always a new backup to a new share.

Also, you should not need to add anything to SMB extra settings; just having "Enhanced macOS interoperability" is enough

Same for me! Since 7.2.2 I cannot make any Time Machine back-ups anymore.

Now on 7.2.3 and Mac OS 26.2 (Mac mini M4) and tried everything, nothing works.
This is so frustrating. Cannot understand why break this feature in first place.

I'm pretty sure there's still some issue, since there are multiple users having the problem, just strange that it doesn't affect everyone, and that I cannot reproduce it.

For the users that it still doesn't work with 7.2.3, does it work if you downgrade to 7.1.4?

I’m a new owner. I had this problem with 7.2.2, upgraded to 7.2.3. Still getting the “can’t create disk image” error.

I tried deleting the share and making a new one with 7.2.3. No luck. I looked at your settings and duplicated those, still errors. Note the only difference between your settings and mine is that you assign the share to a specific disk in your array. Mine used the setting to allow the share to be spread across the entire array. Changing to use a specific drive did not fix the problem.

The difference between your setup and mine is that you have a long running unRAID server, kept up to date over time (I assume). Mine is a new server created 3 weeks ago with 7.2.2.

The backup proceeds, the Mac says “preparing backup…”. The Main screen in the web UI shows continuous disk activity for about 10 minutes, then the error occurs. I look in the share and see a temporary sparsebundle folder structure. I’m only guessing, but it may be trying to rename the top level bundle directory and failing, or maybe it’s trying to set permissions or extra Apple ones.

Output of testparm:

root@unraid:~# testparm
Load smb config files from /etc/samba/smb.conf
lpcfg_do_global_parameter: WARNING: The "null passwords" option is deprecated
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
# Global parameters
[global]
        bind interfaces only = Yes
        disable netbios = Yes
        disable spoolss = Yes
        interfaces = 192.168.0.49/16 127.0.0.1
        load printers = No
        logging = syslog@0
        map to guest = Bad User
        max open files = 40960
        multicast dns register = No
        ntlm auth = ntlmv1-permitted
        null passwords = Yes
        passdb backend = smbpasswd
        printcap name = /dev/null
        security = USER
        server min protocol = SMB2
        server multi channel support = No
        server signing = if_required
        server string = Media server
        show add printer wizard = No
        smb1 unix extensions = No
        smb3 directory leases = No
        fruit:nfs_aces = No
        idmap config * : range = 3000-7999
        idmap config * : backend = tdb
        acl allow execute always = Yes
        aio read size = 0
        aio write size = 0
        create mask = 0777
        directory mask = 0777
        hide dot files = No
        include = /etc/samba/smb-shares.conf
        invalid users = root
        use sendfile = Yes
        wide links = Yes

[TM]
        comment = Time Machine
        guest ok = Yes
        path = /mnt/user/TM
        read only = No
        vfs objects = catia fruit streams_xattr
        fruit:time machine max size = 5000000M
        fruit:time machine = yes
        fruit:metadata = stream
        fruit:encoding = native

[windows-backup]
        guest ok = Yes
        path = /mnt/user/windows-backup
        read only = No
        vfs objects = catia fruit streams_xattr
        fruit:encoding = native

3 hours ago, mschwartz said:

The difference between your setup and mine is that you have a long running unRAID server, kept up to date over time (I assume). Mine is a new server created 3 weeks ago with 7.2.2.

That should not make any difference, but just in case, I tried a new trial install with 7.2.2 using all defaults, upgraded to 7.2.3 and it still works for me.

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:

1. OS Updates: Both Unraid and macOS Tahoe were updated to the latest versions to rule out known Samba/Sequoia-era bugs.

2. ZFS Dataset Tuning:

   • Set xattr=sa and dnodesize=auto.

   • Confirmed casesensitivity=sensitive.

3. 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.

4. 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.

5. 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.

1 hour ago, Rafaqs said:

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:

1. OS Updates: Both Unraid and macOS Tahoe were updated to the latest versions to rule out known Samba/Sequoia-era bugs.

2. ZFS Dataset Tuning:

   • Set xattr=sa and dnodesize=auto.

   • Confirmed casesensitivity=sensitive.

3. 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.

4. 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.

5. 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.

[SOLVED] Time Machine on Unraid 7.2.3 + macOS Tahoe: Native SMB failures vs. Docker Success

Hi 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:

1. 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.

2. 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.

3. 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.

4. 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!

Sorry for the late replies... I was digging and waiting on some more info from the linux samba team... glad you found a solution.

Some base stock samba info

vfs objects = catia fruit streams_xattr

fruit:metadata = stream

fruit:resource = stream

fruit:locking = none

fruit:time machine = yes

ea support = yes

store dos attributes = yes

This is textbook-correct bare min for stock samba:

• macOS ≥ Big Sur

• SMB-based Time Machine

• streams_xattr instead of netatalk...

But To answer some of your questions...

Samba 4.21.x + macOS Tahoe SMB client regression

macOS Tahoe (26.x) tightened SMB2/3 create semantics for Time Machine:

During sparsebundle creation, macOS now:

• Performs multiple parallel SMB CREATE requests

• Uses compound requests with durable handles

• Heavily stresses:

  • NTCreateAndX

  • extended attributes

  • streams + locking state

  • rename atomicity

Unraid’s Samba path fails before file creation completes:

“The backup disk image could not be created”

This is a metadata handshake failure, not a storage failure.

Unraid’s Samba is not “stock Samba”

*This is critical. What I have found.

Unraid:

• Injects wrapper logic

• Auto-generates smb.conf fragments

• Applies opinionated defaults

• Mixes:

  • POSIX ACL translation

  • user/group coercion

  • share-level overrides

Even when you use SMB Extras, Unraid still:

• Controls startup order

• Owns winbind behavior

• Manages mdns / avahi

• Applies internal permission normalization

*Docker bypasses all of this. *This is a reason why I run my own smb config...

ZFS makes the bug deterministic

Zfs is strict, and there are so,e other zfs settings that need to be set / watched...

macOS expects AFP-like semantics emulated over SMB.

When Samba’s fruit module almost matches expectations but fails one atomic metadata edge case → macOS aborts immediately.

Some ZFS checks:
zfs list

asumed pool / datset is
tank/TimeMachine

Check current ZFS settings:

zfs get xattr,dnodesize,recordsize,atime,case,acltype,aclinherit tank/TimeMachine

Set required / recommended properties
zfs set xattr=sa tank/TimeMachine

*Only applies to new files. Existing files keep old layout.

Dnode sizing (metadata-heavy workloads):

zfs set dnodesize=auto tank/TimeMachine

Case sensitivity (must be set at creation time)

*(this is set at dataset creation...)

check: zfs get case tank/TimeMachine

how to set (zfs master or teminal): zfs create -o case=sensitive tank/TimeMachine

ACL behavior (recommended for SMB/macOS):

zfs set acltype=posixacl tank/TimeMachine

zfs set aclinherit=passthrough tank/TimeMachine

Check:

zfs get acltype,aclinherit tank/TimeMachine

RE verify:

zfs get xattr,dnodesize,case,acltype,aclinherit,atime tank/TimeMachine

expected ideal output:

xattr sa

dnodesize auto

case sensitive

acltype posixacl

aclinherit passthrough

atime off

Why force user = root is NOT the issue

This gets blamed a lot. Incorrectly.

You already proved:

• Multiple Macs

• Multiple NICs

• Multiple filesystems

• Same failure point

If this were permissions:

• You’d see partial sparsebundle creation

• You’d see permission denied

• You’d see retries

Instead you get instant abort. That’s protocol-level, not POSIX.

@JorgeB Why Unraid specifically is at fault (not Samba in general)
Same macOS + same Samba version works on:

• TrueNAS SCALE

• Linux + system Samba

• Dockerized Samba

Fails on:

• Unraid native SMB

This isolates the bug to:

Unraid’s Samba integration layer

Not Samba upstream.
Not ZFS.
Not macOS alone.

Unraids has a good implementation, just doesn't fit all use cases... there is no samba config option that can be implemented to easily address users issues on apple time machine.
*I've even see this where a old time machine configuration break due to smb share config changes and it not be samba its go to the dam Apple delta time machine and reconnect!

Similar to zfs snapshots. apple time machine are snapshots on apple hfs. It's entirely metadata to storage. Apple aborts if any degradation is detected to preserve the snapshot data.
even when Apple makes a client connection to unraid and how unraids samba/avahi and settings handles CIFS is affected here. I did a deep dive with a another person on the forum with apple and rsync. The underlying issues is in how apple clients connects. The docker just has a known working state which can be implemented on bare unraid. But yes, a Docker version of this is fine for a good soltuon for others.

So to Recap Based on behavior, logs, and known Samba issues:

Compound SMB CREATE + streams_xattr + Unraid ACL coercion
→ breaks durable handle negotiation
→ macOS aborts sparsebundle creation

This aligns with:

• Failure timing

• Docker success

• ZFS sensitivity

• Tahoe-only regressions

18 minutes ago, bmartino1 said:

Desculpe a demora nas respostas... Estava pesquisando e aguardando mais informações da equipe do Samba para Linux... Que bom que você encontrou uma solução.

Algumas informações básicas sobre samba

vfs objects = catia fruit streams_xattr

fruit:metadata = stream

fruit:resource = stream

fruit:locking = none

fruit:time machine = yes

ea support = yes

store dos attributes = yes

Esta é a quantidade mínima recomendada para o Stock Samba, conforme descrito nos livros :

• macOS ≥ Big Sur

• Máquina do Tempo baseada em SMB

• streams_xattr em vez de netatalk...

Mas, para responder a algumas das suas perguntas...

Regressão do cliente SMB Samba 4.21.x + macOS Tahoe

O macOS Tahoe (26.x) aprimorou a semântica de criação de SMB2/3 para o Time Machine:

Durante a criação do sparsebundle, o macOS agora:

• Executa várias solicitações SMB CREATE em paralelo.

• Utiliza solicitações compostas com alças duráveis.

• Enfatiza bastante:

  • NTCreateAndX

  • atributos estendidos

  • fluxos + estado de bloqueio

  • renomear atomicidade

O caminho Samba do Unraid falha antes da conclusão da criação do arquivo:

Trata-se de uma falha na negociação de metadados , não de uma falha de armazenamento.

O Samba do Unraid não é o "Samba padrão".

*Isto é crucial. Foi o que descobri.

Unraid:

• Injeta lógica de encapsulamento

• Gera automaticamente fragmentos do arquivo smb.conf.

• Aplica padrões definidos por opinião.

• Misturas:

  • Tradução POSIX ACL

  • coerção de usuário/grupo

  • substituições de nível de compartilhamento

Mesmo ao usar o SMB Extras , o Unraid ainda:

• Ordem de inicialização dos controles

• Comportamento winbind proprietário

• Gerencia mdns / avahi

• Aplica a normalização de permissões internas.

*O Docker ignora tudo isso . *Essa é uma das razões pelas quais eu uso minha própria configuração SMB...

O ZFS torna o bug determinístico

O ZFS é rigoroso e existem algumas outras configurações do ZFS que precisam ser definidas/monitoradas...

O macOS espera uma semântica semelhante à do AFP emulada sobre SMB .

Quando o módulo de frutas do Samba quase corresponde às expectativas, mas falha em um caso extremo de metadados atômicos → o macOS aborta imediatamente .

Algumas verificações do ZFS:
zfs list

pool/conjunto de dados assumido é
tank/TimeMachine

Verifique as configurações atuais do ZFS:

zfs get xattr,dnodesize,recordsize,atime,case,acltype,aclinherit tank/TimeMachine

Defina as propriedades necessárias/recomendadas.
zfs set xattr=sa tank/TimeMachine

* Aplica-se somente a novos arquivos . Os arquivos existentes mantêm o layout antigo.

Dimensionamento de nós D (cargas de trabalho com grande volume de metadados):

zfs set dnodesize=auto tank/TimeMachine

Diferenciação entre maiúsculas e minúsculas (deve ser definida no momento da criação)

*(Esta configuração é definida na criação do conjunto de dados...)

verificar: zfs get case tank/TimeMachine

Como configurar (mestre ZFS ou terminal):zfs create -o case=sensitive tank/TimeMachine

Comportamento da ACL (recomendado para SMB/macOS):

zfs set acltype=posixacl tank/TimeMachine

zfs set aclinherit=passthrough tank/TimeMachine

Verificar:

zfs get acltype,aclinherit tank/TimeMachine

RE verificar:

zfs get xattr,dnodesize,case,acltype,aclinherit,atime tank/TimeMachine

Resultado ideal esperado:

xattr sa

tamanho do nó automático

maiúsculas e minúsculas

acltype posixacl

passagem aclinherit

um tempo livre

Por que force user = rootNÃO é esse o problema?

Isso é frequentemente culpado. Incorretamente.

Você já provou:

• Vários Macs

• Múltiplas placas de rede

• Vários sistemas de arquivos

• Mesmo ponto de falha

Se fossem permissões:

• Você veria a criação parcial de sparsebundles.

• Você veria a permissão negada.

• Você veria novas tentativas.

Em vez disso, você obtém um aborto instantâneo . Isso é uma limitação do protocolo, não do POSIX.

@JorgeBPor que o problema é especificamente com o Unraid (e não com o Samba em geral)?
O mesmo macOS e a mesma versão do Samba funcionam em:

• Balança TrueNAS

• Linux + sistema Samba

• Samba em Docker

Falha em:

• SMB nativo do Unraid

Isso isola o bug em:

Não é o Samba upstream.
Não é o ZFS.
Não é apenas o macOS.

O Unraid tem uma boa implementação, só não se adapta a todos os casos de uso... não existe uma opção de configuração do Samba que possa ser implementada para resolver facilmente os problemas dos usuários com o Time Machine da Apple.
*Já vi isso acontecer quando uma configuração antiga do Time Machine quebra devido a alterações na configuração do compartilhamento SMB e, em vez de ser o Samba, o problema é o Time Machine Delta da Apple, que reconecta!

Similar aos snapshots do ZFS. O Time Machine da Apple são snapshots no HFS da Apple. É tudo metadados para armazenamento. A Apple interrompe a conexão se detectar qualquer degradação para preservar os dados do snapshot.
Mesmo quando a Apple estabelece uma conexão de cliente com o Unraid, a forma como o Samba/Avahi e as configurações do Unraid lidam com o CIFS é afetada. Fiz uma análise aprofundada com outra pessoa no fórum sobre a Apple e o rsync. O problema subjacente está em como os clientes da Apple se conectam. O Docker tem um estado funcional conhecido que pode ser implementado diretamente no Unraid. Mas sim, uma versão em Docker disso é uma boa solução para outros usuários.

Resumindo, com base no comportamento, nos registros e nos problemas conhecidos do Samba:

Isso está de acordo com:

• Momento da falha

• Docker com sucesso

• Sensibilidade ZFS

• Regressões exclusivas de Tahoe

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!

5 hours ago, Rafaqs said:

[SOLVED] Time Machine on Unraid 7.2.3 + macOS Tahoe: Native SMB failures vs. Docker Success

Hi 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:

1. 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.

2. 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.

3. 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.

4. 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!

@Rafaqs Thank you for this solution. That worked here. Well done!

@JorgeB Thank you for looking into this, perhaps there is a larger underlying issue within Unraid;

@bmartino1 Thank you for your work in this space and lending your experience.

Have a great Holiday period!

11 hours ago, Rafaqs said:

The ZFS optimization tips you provided (xattr=sa, dnodesize=auto, and acltype=posixacl) are gold.

Do you mean that adding these to SMB extras resolves the issue? And I don't mean using the container option.

30 minutes ago, JorgeB said:

Do you mean that adding these to SMB extras resolves the issue? And I don't mean using the container option.

they are not required. They can assit zfs with time machine shares.

Example ZFS passed into unraid for samba.

root@pve:/data# zfs list

NAME USED AVAIL REFER MOUNTPOINT

VMs 103G 797G 96K /VMs

VMs/pve 103G 797G 77.9G /VMs/pve

data 2.07T 12.4T 67.8M /data

data/Dockers 106G 12.4T 26.0G /data/Dockers

data/PBS 19.6G 12.4T 19.6G /data/PBS

data/PVE 168K 12.4T 104K /data/PVE

data/TimeMachine 60.0G 12.4T 30.1G /data/TimeMachine

data/Users 761G 12.4T 761G /data/Users

data/samba 1.15T 12.4T 1.13T /data/samba

root@pve:/data# zfs get xattr,dnodesize,recordsize,atime,case,acltype,aclinherit data/TimeMachine

NAME PROPERTY VALUE SOURCE

data/TimeMachine xattr on inherited from data

data/TimeMachine dnodesize legacy default

data/TimeMachine recordsize 128K default

data/TimeMachine atime off inherited from data

data/TimeMachine casesensitivity sensitive -

data/TimeMachine acltype posix inherited from data

data/TimeMachine aclinherit restricted default

root@pve:/data#

Where I could runn the above and imporve my zfs and apple time machine connections...

I mentioned zfs extra options as that is whats recommend via samba linux team with zfs. There are a few guides via Google that go over it and it was worth a mention. Required no, helps yes. When users with default samba default unraid config have isseus its worth a try / test.

other random google data on it as well:
https://discussions.apple.com/thread/256112267?sortBy=rank
https://github.com/jollyjinx/ZFS-TimeMachine

Where most of that data came from:
https://prafiles.in/using-zfs-for-timemachine/

50 minutes ago, bmartino1 said:

they are not required. They can assit zfs with time machine shares.

I know that because it works for me without it, I just would like confirmation if it helps users who are having the issue.

On 12/21/2025 at 12:18 PM, JorgeB said:

For the users that it still doesn't work with 7.2.3, does it work if you downgrade to 7.1.4?

It would also be great if someone could confirm this.

While I still cannot reproduce the issue when creating an TM actual backup, but I've found a manual way to trigger the bug, and can confirm it's still present in Unraid 7.2.3, not sure how, since Samba 2.23.4 was supposed to fix exactly this bug, but there's no doubt for me now that it's still there.

LT is aware of the issue and will investigate. Possibly the patch didn't get correctly applied to Samba 4.23.4, only Samba 4.22.7, but now that I can reproduce it 100% of the time, it should be easier to troubleshoot.

Until this is resolved, recommend that anyone who uses TM remain on 7.1.4 or use the container option with 7.2.x