Hi. I'm running this docker to backup a Mac Studio (just over 1TB used out of 2TB) to a share dedicated on a 3TB drive on Unraid 6.12.13. I used all the default settings for this docker except password and max storage (set to 2.6TB). There's a 2.5GB Ethernet connection from workstation to server.

 

Time Machine starts and stops randomly and never seems to complete a backup. Sometimes it reports the free space correctly, sometimes says "0". Sometimes I can connect to the TimeMachine SMB from Finder, sometimes Finder fails to connect.

 

After about a week Unraid says 2.16TB of the 3TB disk has been used, but Time Machine still says "Oldest Backup: None, Latest Backup: None".  Time Machine will open on my Mac, but only lets me look back about a day from the present time. (I have not tried to restore anything). That -1 day was true for several days (until I stopped running the docker).

 

TimeMachine Docker log contains this:

Samba name server TIMEMACHINE is now a local master browser for workgroup WORKGROUP on subnet 192.168.0.2

*****
smb2_validate_message_id: smb2_validate_message_id: client used more credits than granted, mid 2, charge 1, credits_granted 0, seqnum low/range: 2/0
smb2_validate_message_id: smb2_validate_message_id: client used more credits than granted, mid 2, charge 1, credits_granted 0, seqnum low/range: 2/0
smb2_validate_message_id: smb2_validate_message_id: client used more credits than granted, mid 2, charge 1, credits_granted 0, seqnum low/range: 2/0
smb2_validate_message_id: smb2_validate_message_id: client used more credits than granted, mid 2, charge 1, credits_granted 0, seqnum low/range: 2/0
smb2_validate_message_id: smb2_validate_message_id: client used more credits than granted, mid 2, charge 1, credits_granted 0, seqnum low/range: 2/0
smb2_validate_message_id: smb2_validate_message_id: client used more credits than granted, mid 2, charge 1, credits_granted 0, seqnum low/range: 2/0

 

Maybe co-incidence, but other well established SMB devices on the same network seemed to have issues while the Docker was running. (connection failures resolved by substituting IP address).

 

The closest to these symptoms I found was on Apple's support site (not related to Unraid) which suggested the problem was in the external drive, which should be replaced.

 

Can you suggest any troubleshooting steps?

 

Thanks!

 

***UPDATE***

Following AeroMaestro's example posted later in this thread, I installed the latest update (as of 3/3/2024) and changed the workgroup name to a different unique name. After this I was FINALLY able to complete a full backup without hangs and failures, and all seems to be working.

Edited March 6, 20242 yr by malebron

Hey folks. My timemachine implementation has gone all wonky.

 

After a full unRAID reboot, I can get it to run for a while. (Have to reboot my client computers, too.) 

But then after 30 minutes or so it just keeps spitting out this error:

 

scavenger_timer: Failed to cleanup share modes and byte range locks for file 52:11540474045137110:0 open 3433579876
scavenger_timer: Failed to cleanup share modes and byte range locks for file 52:11540474045137784:0 open 2202357559
scavenger_timer: Failed to cleanup share modes and byte range locks for file 52:648799821323949090:0 open 3485260591
scavenger_timer: Failed to cleanup share modes and byte range locks for file 52:11540474045138732:0 open 4061891360
scavenger_timer: Failed to cleanup share modes and byte range locks for file 52:648799821323949088:0 open 541969747
scavenger_timer: Failed to cleanup share modes and byte range locks for file 52:648799834239568738:0 open 2356579153

 

... and my timemachine backups fail.  Here's what I've tried:

 

* I've rebooted everything multiple times, restarted timemachine docker many many times, too.

* I thought maybe there was some corrupted file in one of my backups, so I've deleted all files out of the timemachine share.

* I've run the permissions command as suggested by the timemachine docker template:

sudo chown -R 1000:1000 /mnt/user/timemachine/

* I've turned SMB sharing off and on again.

* I've completely uninstalled the timemachine docker, deleted the timemachine share, and reinstalled everything.

 

I'm not exactly sure if this started after my update to unRAID 6.12.8 or not.  I think yes, but it's possibly coincidental.

Edited February 20, 20242 yr by AeroMaestro

On 2/20/2024 at 9:08 AM, AeroMaestro said:

I'm not exactly sure if this started after my update to unRAID 6.12.8 or not.  I think yes, but it's possibly coincidental.

Actually, after some more experimenting, it seems the problem might be caused by the latest MacOS release 14.3.1.  I have two clients that are both on MacOS 14.3.1 and they're both having this same issue.  I have one older macbook on an earlier release of MacOS and it continues to work without any troubles.

Edited February 21, 20242 yr by AeroMaestro
clearing up a possible false lead

I've never had this issue with this docker but often with unraid I have to do a recovery reinstall of macOS after updates. Might be worth a try for you.

I started noticing some messages in the logs about  TIMEMACHINE being "a local master browser for workgroup WORKGROUP" -- sometimes it seemed to revert to unRAID, and sometimes it would switch back to timemachine. I really don't understand SMB in this regard, but I edited the timemachine to be on its own workgroup (WORKGROUP2) so it wouldn't conflict with unRAID's master status.  At least, in my mind, that seemed to make sense--perhaps my client computers were having trouble connecting to the timemachine share because there was confusion about who the master was and where the share was located.

 

BUT also, it looks like this docker pushed an update last night.  I'm not sure what's changed, but it appears to be working OK again now. I have three clients all connected and backing up and it's been running for about six hours without error so far.

So I'm not exactly sure if switching the workgroup fixed my issue, or if the latest update fixed it, but things are still running OK.  Apologies to anybody searching for a solution to a similar issue -- I wasn't very scientific here.

Edited February 21, 20242 yr by AeroMaestro
added more detail

On 2/21/2024 at 9:06 AM, AeroMaestro said:

I started noticing some messages in the logs about  TIMEMACHINE being "a local master browser for workgroup WORKGROUP" -- sometimes it seemed to revert to unRAID, and sometimes it would switch back to timemachine. I really don't understand SMB in this regard, but I edited the timemachine to be on its own workgroup (WORKGROUP2) so it wouldn't conflict with unRAID's master status.  At least, in my mind, that seemed to make sense--perhaps my client computers were having trouble connecting to the timemachine share because there was confusion about who the master was and where the share was located.

 

BUT also, it looks like this docker pushed an update last night.  I'm not sure what's changed, but it appears to be working OK again now. I have three clients all connected and backing up and it's been running for about six hours without error so far.

So I'm not exactly sure if switching the workgroup fixed my issue, or if the latest update fixed it, but things are still running OK.  Apologies to anybody searching for a solution to a similar issue -- I wasn't very scientific here.

 

When I read your post I thought I'd give this container another shot. (I quit trying after my issues posted above). Like you I installed the latest update and changed WORKGROUP to MACGROUP.

 

What do you know, after many many weeks of trying I finally got a complete backup with no hangs or failures!

 

Neither the native method (following SpaceinvaderOne's instructions) nor this container worked for me until now.

 

Thanks!

Has anyone noticed that no matter what you set the password to in the template, it ends up being the default password?  The docker statement shows it on the screen after editing any setting, and it's just setting it to the default value, no matter that I have a different password configured...

13 hours ago, Taige said:

Has anyone noticed that no matter what you set the password to in the template, it ends up being the default password?  The docker statement shows it on the screen after editing any setting, and it's just setting it to the default value, no matter that I have a different password configured...

This is definitely NOT my experience. I imagine you have something misconfigured (very easy to do). If you want to provide specifics of your configuration I’d be glad to help with this if I can.

I've been using this off and on for a while.

All of a sudden, the container size grows while I'm doing a backup. My file mapping is mapped to a share on the array. Any idea what the problem may be?

 

When i select container size on the app screen, my TM has a container size of 51gb. Everything else is 2gb or less. My total docker image is 80 GB.

 

 

On 5/7/2024 at 7:22 AM, MarshR said:

All of a sudden, the container size grows while I'm doing a backup. My file mapping is mapped to a share on the array. Any idea what the problem may be?

Maybe this from the first page of this thread?

https://forums.unraid.net/topic/123985-timemachine-application-support-thread/?do=findComment&comment=1131485

 

Has anyone managed to use this reliably for more than a few months? I find that after a few weeks or months, timemachine on my MBP will fail to backup to the original .sparsebundle file/folder and create a new one named .sparsebundle1. The original sparsebundle will be rendered completely inaccessible and I have no other option but to simply delete it.. is there a way to prevent this from happening?

I never tried setting things up the 'standard' way (without this docker), as detailed here: https://docs.unraid.net/unraid-os/guides/configuring-time-machine/I
Does anyone know if that is a more reliable method of getting things set up?

I am having trouble running this app. I left everything at default even the suggested user password i.e. I made NO changes to the image. Once the container is running, I stop it and enter the terminal command of "sudo chown -R 1000:1000 /mnt/user/timemachine/'". The terminal accepts the command without complaint.

I then restart the container. However, upon entering the system setting on my Mac (MacMini with M4 chip), I get the following error message s saying it can not add additional users: see attached.

I am also including the container log file: attached

container log.txt

Edited June 20, 20251 yr by fourex73
added screenshot

Anyone know how to fix this "set_canon_ace_list: sys_acl_set_file on file [MacBookPro.sparsebundle/mapped/25d]: (Not supported)"?

Update:

its fixed using "zfs set acltype=posixacl <pool>/<dataset>"

Edited October 15, 2025Oct 15 by Kira

Hello everyone.

First of all, I would like to thank you for the Timemachine Container. It works perfectly and makes my life so much easier.

The backups work and I can also search through all of them.

However, I have noticed some error messages in the log file that I cannot explain:

apply_new_nt_acl: inherit_new_acl failed for .com.apple.TimeMachine.iotest.08244815-1517-4DE3-BE48-1D9FF6F2F873 with NT_STATUS_ACCESS_DENIED
apply_new_nt_acl: inherit_new_acl failed for MacBook Pro von Gabriele.sparsebundle/com.apple.TimeMachine.MachineID.plist.tmp with NT_STATUS_ACCESS_DENIED
apply_new_nt_acl: inherit_new_acl failed for MacBook Pro von Gabriele.sparsebundle/com.apple.TimeMachine.MachineID.plist.tmp with NT_STATUS_ACCESS_DENIED
apply_new_nt_acl: inherit_new_acl failed for .com.apple.TimeMachine.iotest.8CA56F2A-02FF-4D1C-9BF7-1BCA88BCD80F with NT_STATUS_ACCESS_DENIED

Does anyone have any idea what this could be?

Thank you very much for your help.

Janot

On 12/7/2025 at 4:08 AM, Janot said:

However, I have noticed some error messages in the log file that I cannot explain:

apply_new_nt_acl: inherit_new_acl failed for .com.apple.TimeMachine.iotest.08244815-1517-4DE3-BE48-1D9FF6F2F873 with NT_STATUS_ACCESS_DENIED
apply_new_nt_acl: inherit_new_acl failed for MacBook Pro von Gabriele.sparsebundle/com.apple.TimeMachine.MachineID.plist.tmp with NT_STATUS_ACCESS_DENIED
apply_new_nt_acl: inherit_new_acl failed for MacBook Pro von Gabriele.sparsebundle/com.apple.TimeMachine.MachineID.plist.tmp with NT_STATUS_ACCESS_DENIED
apply_new_nt_acl: inherit_new_acl failed for .com.apple.TimeMachine.iotest.8CA56F2A-02FF-4D1C-9BF7-1BCA88BCD80F with NT_STATUS_ACCESS_DENIED

Does anyone have any idea what this could be?

It's a configuration issue, for some reason the default on the unraid app is setup to support Windows ACLs, but the default on the original docker image is not.

Change the docker image settings:

• SMB_VFS_OBJECTS (SMB vfs objects): drop acl_xattr so the value should be fruit streams_xattr

• SMB_NFS_ACES (SMB fruit:nfs_aces): change it to no

This made those errors go away for me.

Hi chmmr, thanks for your reply.

I just made the changes, and it seems to work!

Thanks for your support.

Janot

3 hours ago, chmmr said:

This made those errors go away for me.

I haven’t had any issues with backups to this docker but decided to test your recommended settings anyway. It’s hard to really do a good comparison of multiple backups but my typical backup takes ~20 minutes. This one took less than 5 minutes. I think I’ll keep the changes for a while.

I'm having a strange issue with the docker icon missing (not downloading).

This is in the logs, with nothing else helpful around it:

TimeMachine: Could not download icon https://upload.wikimedia.org/wikipedia/de/f/f4/Time_Machine_%28Apple%29_Logo.png

I can download that file manually using curl from the unraid cli. I've tried other urls in the docker settings as well, with the same problem.

Does anyone have any ideas on what might be wrong and how to fix it?

The rest of the docker works great and has been for several years.

docker run command

docker run
  -d
  --name='TimeMachine'
  --net='br0'
  --ip='192.168.11.211'
  --pids-limit 2048
  -e TZ="Australia/Sydney"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Tower"
  -e HOST_CONTAINERNAME="TimeMachine"
  -e 'VOLUME_SIZE_LIMIT'='4 T'
  -e 'TM_USERNAME'='timemachine'
  -e 'PASSWORD'='redacted'
  -e 'ADVERTISED_HOSTNAME'='timemachine'
  -e 'CUSTOM_SMB_CONF'='false'
  -e 'CUSTOM_USER'='false'
  -e 'DEBUG_LEVEL'='1'
  -e 'MIMIC_MODEL'='TimeCapsule8,119'
  -e 'EXTERNAL_CONF'=''
  -e 'HIDE_SHARES'='no'
  -e 'TM_GROUPNAME'='timemachine'
  -e 'TM_UID'='1000'
  -e 'SET_PERMISSIONS'='false'
  -e 'SMB_INHERIT_PERMISSIONS'='no'
  -e 'SMB_NFS_ACES'='no'
  -e 'SMB_METADATA'='stream'
  -e 'SMB_PORT'='445'
  -e 'SMB_VFS_OBJECTS'='fruit streams_xattr'
  -e 'WORKGROUP'='WORKGROUP'
  -e 'TM_GID'='1000'
  -e 'SHARE_NAME'='TimeMachine'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.icon='https://upload.wikimedia.org/wikipedia/de/f/f4/Time_Machine_%28Apple%29_Logo.png'
  -v '/mnt/user/DockerTimeMachine/':'/opt/timemachine':'rw'
  --hostname timemachine
  --log-driver syslog
  --log-opt syslog-address=udp://127.0.0.1:541 'mbentley/timemachine'

56067ea7a693cbadaedf8494eb60c84e91cac5a5890e50044ba33d94bfc188dc

The command finished successfully!

Edited December 28, 2025Dec 28 by Jorgen

Hello Jorgen,

I had them same problem as you and I don't know why they icon is not loading. Is it a problem with them size? I don't know.

What I have done, I changed the icon path in : https://cdn.jim-nielsen.com/macos/1024/time-machine-2019-09-25.png?rf=1024

This works! Maybe the maintainer of this docker could find a solution for this problem.

Regards

Janot

On 12/29/2025 at 7:21 PM, Janot said:

Hello Jorgen,

I had them same problem as you and I don't know why they icon is not loading. Is it a problem with them size? I don't know.

What I have done, I changed the icon path in : https://cdn.jim-nielsen.com/macos/1024/time-machine-2019-09-25.png?rf=1024

This works! Maybe the maintainer of this docker could find a solution for this problem.

Regards

Janot

Thanks, that resolved it for me too!

I have the Docker container running and don’t see anything obviously wrong, but when I attempt to configure Settings - Time Machine, it returns the error:

The selected network backup disk does not support the required capabilities.
Please be sure Time Machine capabilities are enabled on the server for this volume or choose a different network backup volume.

Docker Launch Run

docker run
  -d
  --name='TimeMachine'
  --net='mynet'
  --ip='10.0.0.26'
  --pids-limit 2048
  -e TZ="America/Los_Angeles"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="SERVER"
  -e HOST_CONTAINERNAME="TimeMachine"
  -e 'VOLUME_SIZE_LIMIT'='2 T'
  -e 'TM_USERNAME'='timemachine'
  -e 'PASSWORD'='timemachine'
  -e 'ADVERTISED_HOSTNAME'='timemachine'
  -e 'CUSTOM_SMB_CONF'='false'
  -e 'CUSTOM_USER'='false'
  -e 'DEBUG_LEVEL'='1'
  -e 'MIMIC_MODEL'='TimeCapsule8,119'
  -e 'EXTERNAL_CONF'=''
  -e 'HIDE_SHARES'='no'
  -e 'TM_GROUPNAME'='users'
  -e 'TM_UID'='99'
  -e 'SET_PERMISSIONS'='false'
  -e 'SMB_INHERIT_PERMISSIONS'='no'
  -e 'SMB_NFS_ACES'='yes'
  -e 'SMB_METADATA'='stream'
  -e 'SMB_PORT'='445'
  -e 'SMB_VFS_OBJECTS'='acl_xattr fruit streams_xattr'
  -e 'WORKGROUP'='TIMEMACHINE'
  -e 'TM_GID'='100'
  -e 'SHARE_NAME'='TimeMachine'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.icon='https://upload.wikimedia.org/wikipedia/de/f/f4/Time_Machine_%28Apple%29_Logo.png'
  -v '/mnt/mediapool/timemachine/':'/opt/timemachine':'rw'
  --hostname timemachine 'mbentley/timemachine'
a59f6ce6ea90f68d62c6d816375e70eb6999974546eada6617e5d41d39186b8a

Container Logs

chpasswd: password for 'timemachine' changed
dbus-daemon[39]: [system] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted
Found user 'avahi' (UID 86) and group 'avahi' (GID 86).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Loading service file /etc/avahi/services/smbd.service.
Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.0.26.
New relevant interface eth0.IPv4 for mDNS.
Joining mDNS multicast group on interface lo.IPv6 with address ::1.
New relevant interface lo.IPv6 for mDNS.
Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
New relevant interface lo.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for 10.0.0.26 on eth0.IPv4.
Registering new address record for ::1 on lo.*.
Registering new address record for 127.0.0.1 on lo.IPv4.
Server startup complete. Host name is timemachine.local. Local service cookie is 3653652982.
Service "timemachine" (/etc/avahi/services/smbd.service) successfully established.
INFO: CUSTOM_SMB_CONF=false; generating [global] section of /etc/samba/smb.conf...
INFO: Creating /var/log/samba/cores
INFO: Avahi - generating base configuration in /etc/avahi/services/smbd.service...
INFO: Avahi - using timemachine as hostname.
INFO: Avahi - adding the 'dk0', 'TimeMachine' share txt-record to /etc/avahi/services/smbd.service...
INFO: Group users exists; skipping creation
INFO: User timemachine doesn't exist; creating...
INFO: Using default password: timemachine
INFO: INFO: CUSTOM_SMB_CONF=false; generating [TimeMachine] section of /etc/samba/smb.conf...
INFO: Samba - Created Added user timemachine.
INFO: Samba - Enabled user timemachine.
INFO: Samba - setting password
INFO: SET_PERMISSIONS=false; not setting ownership and permissions for /opt/timemachine
INFO: Avahi - completing the configuration in /etc/avahi/services/smbd.service...
INFO: running test for xattr support on your time machine persistent storage location...
INFO: xattr test successful - your persistent data store supports xattrs
INFO: Detected filesystem for /opt/timemachine is zfs
INFO: entrypoint complete; executing 's6-svscan /etc/s6'
dbus socket not yet available; sleeping...
nmbd version 4.22.6 started.
Copyright Andrew Tridgell and the Samba Team 1992-2025
smbd version 4.22.6 started.
Copyright Andrew Tridgell and the Samba Team 1992-2025
become_local_master_stage2: *****

Samba name server TIMEMACHINE is now a local master browser for workgroup TIMEMACHINE on subnet 10.0.0.26
Time Machine client logs

2026-01-23 15:00:44  Limiting logging for limit: aFewTimes key: "map auto_home"
2026-01-23 15:00:44  Bonjour took 0.2 seconds to resolve 'smb://timemachine@timemachine._smb._tcp.local/TimeMachine' to 'smb://[email protected]/TimeMachine'
2026-01-23 15:01:39  Limiting logging for limit: aFewTimes key: "map auto_home"
2026-01-23 15:01:44  Limiting logging for limit: aFewTimes key: "map auto_home"
2026-01-23 15:01:52  Choosing destination volume
2026-01-23 15:01:54  Prepare destination
2026-01-23 15:01:54  mountNetworkURL: smb://timemachine._smb._tcp.local./TimeMachine airDiskFlags: 0x82
2026-01-23 15:01:54  NetAuth session for 'smb://timemachine._smb._tcp.local./TimeMachine' will use options: {
    AuthType = Time     AuthType = TimeMachine;
2026-01-23 15:01:54  Reporting preparation progress message: 'Mounting “TimeMachine” from “timemachine.local”…', fractionDone: nil
2026-01-23 15:02:01  NAOpenSessionAsync reports sessionStatus: 0, sessionInfo: {
2026-01-23 15:02:01  Mounting share 'TimeMachine' with options: {
    TimeMachineMoun     TimeMachineMount = 1;
2026-01-23 15:02:01  NAMountAsync reports mountStatus: 0, mountInfo: {
    MountPath = "/V     MountPath = "/Volumes/TimeMachine";
2026-01-23 15:02:01  Reporting preparation progress message: 'Checking capabilities of “TimeMachine” from “timemachine.local”…', fractionDone: nil
2026-01-23 15:02:01  Backup images not supported or failed to configure reconnect settings for '/Volumes/TimeMachine'
2026-01-23 15:02:01  Mountpoint '/Volumes/TimeMachine' is still valid
2026-01-23 15:02:01  Unmounting '/Volumes/TimeMachine'
2026-01-23 15:02:01  Reporting preparation error: Error Domain=com.apple.TimeMachine.SettingsExtension Code=3 "The selected network backup disk does not support the required capabilities." UserInfo={NSLocalizedDescription=The selected network backup disk does not support the required capabilities., NSLocalizedRecoverySuggestion=Please be sure Time Machine capabilities are enabled on the server for this volume or choose a different network backup volume.}
2026-01-23 15:02:01  Unmounted '/Volumes/TimeMachine'
2026-01-23 15:02:01  Limiting logging for limit: aFewTimes key: "map auto_home"
2026-01-23 15:02:02  Limiting logging for limit: aFewTimes key: "map auto_home"

/etc/samba/smb.conf from the container:

[global]
   access based share enum = no
   hide unreadable = no
   inherit permissions = no
   load printers = no
   log file = /var/log/samba/log.%m
   logging = file
   max log size = 1000
   security = user
   server min protocol = SMB2
   ntlm auth = no
   server role = standalone server
   smb ports = 445
   workgroup = TIMEMACHINE
   vfs objects = acl_xattr fruit streams_xattr
   fruit:aapl = yes
   fruit:nfs_aces = yes
   fruit:model = TimeCapsule8,119
   fruit:metadata = stream
   fruit:veto_appledouble = no
   fruit:posix_rename = yes
   fruit:zero_file_id = yes
   fruit:wipe_intentionally_left_blank_rfork = yes
   fruit:delete_empty_adfiles = yes

[TimeMachine]
   path = /opt/timemachine
   inherit permissions = no
   read only = no
   valid users = timemachine
   vfs objects = acl_xattr fruit streams_xattr
   fruit:time machine = yes
   fruit:time machine max size = 2 T

Edited January 24Jan 24 by RandoUser

I have the Docker container running and don’t see anything obviously wrong, but when I attempt to configure Settings - Time Machine, it returns the error:

The selected network backup disk does not support the required capabilities.
Please be sure Time Machine capabilities are enabled on the server for this volume or choose a different network backup volume.

FIXED!

It was a client-side issue. I had a custom configuration in /etc/nsmb.conf that had something in it that was causing the problem. I just deleted the whole file which reset MacOS back to its defaults and that resolved the issue. Here's my "bad" /etc/nsmb.conf file in case someone sees something specific that would have caused it.

[default]
# Disable SMB signing (adds overhead)
signing_required=no

# Don’t use NTFS-style resource forks (prevents hidden AppleDouble files)
streams=no

# Force SMB3 only
protocol_vers_map=3

# Avoid directory caching weirdness in Finder
dir_cache=no
dir_cache_off=yes

# Disable file id lookups that slow large dirs
file_ids_off=yes

# Don’t query for file streams on each listing
no_share_cache=yes

port445=no_delayed_ack,no_netbios
notify_off=yes

Just tried to set up this Docker, exactly the same result as for native Unraid...

Any ideas?

Native Unraid Setup:

I am on 7.2.4 ZFS and Tahoe 26.4, I am not able to use Time Machine backup. Everything has been working before and now I have no idea which of all of the fix options I should use?

Able to mount it on Mac and add it as a backup, but once I start the backup, it fails immediately

15 hours ago, 6103242 said:

Just tried to set up this Docker, exactly the same result as for native Unraid...

Any ideas?

Native Unraid Setup:

I am on 7.2.4 ZFS and Tahoe 26.4, I am not able to use Time Machine backup. Everything has been working before and now I have no idea which of all of the fix options I should use?

Able to mount it on Mac and add it as a backup, but once I start the backup, it fails immediately

you most likely have a permission issue.

stop all dockers and run the set new docker safe perm

7 hours ago, bmartino1 said:

you most likely have a permission issue.

stop all dockers and run the set new docker safe perm

Nope, this is not the issue...