Timemachine Application Support Thread

[malebron]

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 by malebron

[AeroMaestro]

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 by AeroMaestro

[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 by AeroMaestro
clearing up a possible false lead

[wgstarks]

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.

[AeroMaestro]

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 by AeroMaestro
added more detail

[malebron]

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!

[Taige]

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

[wgstarks]

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.