Simon Edelmann

Same for me (with 6.11.5, haven‘t tried 6.12 yet), which makes me think it is actually not an issue of configuration. Has anybody ever tried the workaround I posted here? As it sounds so strange, I wonder if this is actually related to the issues with TimeMachine. However that workaround has worked so far…

Does anybody know if it is possible to install a newer/older version of samba in Unraid? I tried to get a precompiled binary for Slackware and used ‚upgradepkg‘ to install it, but when I was running smb commands then I always got „Required file not found“, although the file was there and I could inspect its content via ‚cat‘. I would like to try different versions of samba and check if any of those works..

Hi, I hope it‘s okay to join your discussion having issues with TM backups too. In my case I only started using Unraid with 6.10, and it never worked reliable. (I have this strange behaviour that TM backups are only working when the CPU of the server is under load.) I‘ve tried that. (Actually made a clean Unraid 6.10.3 installation in order to try that.) The initial backup was (kind of) working. It aborted at ~50%, but after changing some SMB configuration in Unraid it was resumed. Incremental backups though was never working reliable, no matter of the configuration I tried.

That‘s interesting… I‘ve tried multiple times in a row already and it never worked until I put load on the server. (I recognised that, because only working backups were happening at night when a rsync script was running on the server.) The manual backup cancellation might be there, because I tried to get a clean log for this post by stopping+manually starting the backup. (Which is strange though, as I didn‘t manually stopped this attempt, but only the attempt before.)

I am struggling with TimeMachine aswell. Have tried TimeMachine docker a few months ago, with no success either. No I am using some strange workaround to get my backups running, but I have to do that manually all the time. Would be interested to know if this is working for anyone else!

Hello, this is one more attempt to debug the bug I (and some others) encounter, using TimeMachine with Unraid. Short description My Mac should backup itself regularly via TimeMachine to the Unraid server. The issue is that after the initial backup, incremental backups sometimes works and sometimes doesn't. If it doesn't work, TimeMachine is getting stuck on connecting. But I noticed a strange coincidence: Whenever I put load on my Unraid's CPU, TimeMachine connects perfectly. Whenever there is no load on my Unraid's CPU, TimeMachine does not connect. Does anyone has an idea why this could happen? My current workaround is to put load on one CPU core via this command: cat /dev/zero > /dev/null Then I manually start the TimeMachine backup. As soon as TimeMachine has connected, I stop the load via Ctrl+C. # # # # # # # # # # Below I will add detailed information about my setup. Also the diagnostics file is attached. Hardware I am using a (Intel) MacBook Pro from 2018 using the newest MacOS Ventura 13.2. My Unraid server is quite small: only 2x4TB + 1TB SSD, an Intel J5040 CPU and 16GB RAM. It is running Unraid 6.11.5 and is mainly used for backups of various webspaces/VPS/etc. as well as my Mac. SMB Settings Enable SMB: Yes Hide dot files: No SMB Multi Channel: Yes Mac interop.: Yes NetBIOS: No WSD: Yes /boot/config/smb-fruit.conf vfs objects = acl_xattr fruit streams_xattr fruit:encoding = native fruit:metadata = stream fruit:posix_rename = yes Share settings (excerpt) Use cache pool: Yes Enable copy-on-write: Yes SMB Export: Yes/Time Machine Time Machine volume limit: 1000000 Security: Private Time Machine logs 2023-02-02 13:16:43 Starting manual backup 2023-02-02 13:16:43 Attempting to mount 'smb://simon@NAS._smb._tcp.local/timemachine' 2023-02-02 13:16:44 Initial network volume options for 'timemachine' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 0, QoS: 0x0, attributes: 0x1C} 2023-02-02 13:16:44 Configured network volume options for 'timemachine' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 30, QoS: 0x20, attributes: 0x1C} 2023-02-02 13:16:44 Mounted 'smb://simon@NAS._smb._tcp.local/timemachine' at '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine' (365.01 GB of 1.05 TB available) 2023-02-02 13:16:45 Skipping periodic backup verification: not needed for an APFS sparsebundle 2023-02-02 13:16:45 'MacBook Pro von Simon.sparsebundle' does not need resizing - current logical size is 996.15 GB (996,147,200,000 bytes), size limit is 996.15 GB (996,147,200,000 bytes) 2023-02-02 13:16:45 Mountpoint '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine' is still valid 2023-02-02 13:16:45 Checking for runtime corruption on '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine/MacBook Pro von Simon.sparsebundle' 2023-02-02 13:17:31 Failed to attach using DiskImages2 to url '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine/MacBook Pro von Simon.sparsebundle', error: Error Domain=NSPOSIXErrorDomain Code=19 "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading} 2023-02-02 13:17:31 Failed to unmount '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine', Disk Management error: { 2023-02-02 13:17:31 Failed to unmount '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine', error: Error Domain=com.apple.diskmanagement Code=0 "No error" UserInfo={NSDebugDescription=No error, NSLocalizedDescription=Kein Fehler.} 2023-02-02 13:17:31 Waiting 60 seconds and trying again. 2023-02-02 13:17:31 Cancelling backup because volume '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine' was unmounted. 2023-02-02 13:17:31 Requested backup cancellation or termination 2023-02-02 13:17:32 Backup cancelled (22: BACKUP_CANCELED) 2023-02-02 13:17:32 Failed to unmount '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine', Disk Management error: { 2023-02-02 13:17:32 Failed to unmount '/Volumes/.timemachine/NAS._smb._tcp.local/66074A41-37F0-44B7-BE6A-9A15AA8C9EE6/timemachine', error: Error Domain=com.apple.diskmanagement Code=0 "No error" UserInfo={NSDebugDescription=No error, NSLocalizedDescription=Kein Fehler.} 2023-02-02 13:17:32 Cleared pending cancellation request nas-diagnostics-20230202-1315.zip Edit: Updated the workaround

I have the same problems with TimeMachine.... sometimes it works, sometimes it doesn't. Recently I discovered that many of my working backups were done in the night around 3:30, when I was not using the computer at all. But my Unraid server does have a cronjob at 3:30, which does a rsync backup of another machine. So today I made an experiment: Last working TimeMachine backup on my Mac was 3 days ago, manually starting the backup did not work. I tried that multiple times in a row. Then I run the rsync-script on my Unraid server and after that run TimeMachine on my Mac again. And magically it worked! I repeated the whole thing twice, TimeMachine seems only to connect to the backup volume if that rsync script is working in background. But when the script was running, TimeMachine worked every time. My Unraid machine is quite small (2 HDDs+1 Cache-SSD for now) and not accessed most of the time. Could it be that something is idle and therefore TimeMachine runs in a timeout and cannot connect? @limetech I will attach logs and my configuration here, just in case it helps... SMB Settings Enable SMB: Yes – Hide dot files: No – SMB Multi Channel: Yes – Mac interop.: Yes – NetBIOS: No – WSD: Yes /boot/config/smb-fruit.conf vfs objects = acl_xattr fruit streams_xattr fruit:encoding = native fruit:metadata = stream fruit:posix_rename = yes And here is the rsync-script, its basically only cleaning up some older backups and then calling rsync, so I guess it is the workload on the server which makes the difference: #!/bin/sh DAY=$(date +%A) if [ -e /mnt/user/server/$DAY ] ; then rm -fr /mnt/user/server/$DAY fi rsync -qaHAXS --delete --inplace --backup --backup-dir=/mnt/user/server/$DAY [email protected]:/home [...] /mnt/user/server/current/ Edit: I experimented with different approaches to put load on the server. TimeMachine backup works, if: - rsync script is running (see above) - I stress test my cpu with this command: for i in $(seq $(getconf _NPROCESSORS_ONLN)); do yes > /dev/null & done TimeMachine backup does not work, if: - Unraid server is not in use - I copy large files from Unraid to my Mac - I copy large files from my Mac to Unraid nas-diagnostics-20230122-1201.zip

Hello there! not sure if anyone is still reading here, but today I took another attempt to fix TimeMachine with Unraid and I got my incremental backup working again. I compared the active smb setting from Unraid and the docker-timemachine container and noticed a few differences, which I then tried one by one until I was able to identify a working configuration: ### SETTINGS / SMB Settings ### Enable SMB: YES (Workgroup) Hide "dot" files: No Enable SMB Multi Channel: Yes Enhanced macOS interoperability: Yes Enable NetBIOS: No Enable WSD: Yes ### SETTINGS / SMB Extra / Samba extra configuration ### logging = 0 #Workaround for log file bug ### /boot/config/smb-fruit.conf ### vfs objects = acl_xattr fruit streams_xattr fruit:encoding = native fruit:metadata = stream fruit:posix_rename = yes Edit: This morning the incremental backup failed again with "Device not supported". After stopping+restarting the array it worked... no configuration changed...

And one more update: I had incremental updates working from October 27th to November 10th. After Nov. 10th no more working backups... I did change nothing... no Mac updates, no Unraid updates, not even a reboot... very strange.

Another update: I now had the same magically working incremental backup as @Jonny13. After rebooting the NAS, I manually started the incremental backup and it worked... but only once! Now backups are failing again... @limetech I've attached the diagnostic file. If there is anything I can help with for debugging this issue, please let me know. nas-diagnostics-20221027-2223.zip

@Jonny13 Kind of the same for me. The first backup was completed successfully just now, after I've added metadata=stream. But incremental backups don't start. I think it was the exact same behavior with MacOS 12 and Unraid 6.10 a few weeks ago. (I then stopped Time Machine backups, so I can't tell if there would have been some magically working backups in between.) Edit: With metadata = stream I now have this issue as well: As soon as I manually start the backup, the log is getting flooded. (Only occurs with Time Machine backups. Accessing other files is fine...) Edit 2: I was wrong... after adding metadata = stream, the logs are getting flooded for every file accessed... Edit 3: In the other thread there was a suggested workaround (logging = 0). Logs are clean again... still Time Machine not working...

I would either try in the custom settings field in SMB options or like this: But I have no idea, if that helps… Edit: I‘ve added fruit:metadata = stream to /boot/config/smb-fruit.conf and restarted samba. (Entering „samba restart“ is not enough for reloading the configuration, I needed to restart the array.) I can confirm that now Timemachine picked up my initial backup. This was not possible without „fruit:metadata = stream“.

Same here! Still not working… Please let us know if adding that line helps for you. Thx!

I have no access to my Unraid system right now, but I can do that in a few days. But at least in my case there was nothing in Unraid logs and I tried with standard configuration. (I am a new Unraid user, already had that problem right after setting up the server, after the initial Timemachine backup.)

What kind of information do you need? (There is another thread here in the forum with many logs…)