Time machine locked sparsebundle

Question

Level 1

0 points

Time machine locked sparsebundle

We are running Time Machine backup using a Mac Mini with OSX Server. Now and then a collegue calls me because he's getting a message "time machine couldn't complete the backup". And to solve the problem, I have to log in to the OSX server and kill the AFP Service with the command sudo killall -TERM AppleFileServer and start the service again using sudo AppleFileServer.

If I try to mount the sparsebundle on the server before I restart the AFP service, it tells me that the images is already in use.

Because we hade to restart the AFP service, we thought that AFP didn't kick idling connections which in turn kept the sparsebundle locked. After configuring AFP to kick idling connections after 2 hours (afp:idleDisconnectOnOff = yes and afp:idleDisconnectOnOff = yes) nothing's changed, the problem is still there.

I've seen alot of post about this concerning Time Capsules and that you should power cycle them and that will solve the problem for now. But this is OSX Server, surely there must be a permanent solutions to this problem? Anyone?

(It's somewhat odd that AFP by default isn't configured to disconnect idle connections, don't you think)

Mac mini, OS X Server, OSx Server on OSx 10.8.2

Posted on Jun 17, 2013 2:39 AM

Reply

Answer 1

rosch

Level 1

13 points

Jul 17, 2013 5:34 AM in response to PatrikPetra

I've got the same issue with OSX Server on a Mac Mini. No solution yet besides restarting the AFP service though...

Reply

Answer 2

Sep 23, 2013 12:19 AM in response to rosch

To complement informations for future readers:

I'm on OSX Server 10.8.5, with Time Machine service enabled.

Some other readings on the internet suggest simply disconnecting the users from the Time Capsule. On OSX Server the equivalent is disconnecting them from the AFP service.

BUT: simply disconnecting them in the File Sharing service doesn't work. They are disconnected, but they cannot do TM backups nevertheless.

Completely restarting the service (switching it off, then wait for the service to finish, then switch on again) does the job and allow TM backup to be made again.

As pointed by PatrikPetra, it's a SHAME to be obliged to do this. It's a shame that "afp:idleDisconnectOnOff = yes" doesn't work, and it's another shame to be obliged to restart the service (potentially closing all other working connections!!) for a simple backup over the network to work.

As a workaround to this unsolved bug, if anyone has the knowledge of the command line equivalent, I would be glad to know the command to properly (stop ; sleep ; kill ; start) the service every night in a cron job, to avoid staring at my server's screen just to do this kind of boring stuff myself. It must be some launchctl command but grepping -i AFP gives me 2 of them, none of which being afpd…

Reply

Answer 3

jedda

Level 1

0 points

Dec 16, 2013 10:53 PM in response to Karmak231

As a workaround to this unsolved bug, if anyone has the knowledge of the command line equivalent, I would be glad to know the command to properly (stop ; sleep ; kill ; start) the service every night in a cron job, to avoid staring at my server's screen just to do this kind of boring stuff myself. It must be some launchctl command but grepping -i AFP gives me 2 of them, none of which being afpd…

I think this will do what you are after:

serveradmin stop afp; sleep 2; serveradmin start afp

Reply

Answer 4

Karmak23

Level 1

0 points

Dec 17, 2013 2:30 AM in response to jedda

Nice, thanks a lot :-)

Reply

Answer 5

Jan 6, 2014 3:57 AM in response to PatrikPetra

We're having the exact same issue and I would love to see a solution which does not require to reboot our OS X server or to disconnect just ALL users.

Thanks a lot for the service restart commands anyway!

Reply

Answer 6

Jan 12, 2014 9:47 AM in response to PatrikPetra

On 10.9's Server.app, there's a Connected Users tab for the File Sharing service. (I'm not sure if this is there for 10.8 or not.) I tried disconnecting all the idle connections for the connected user then trying their backup again. It seemed to start preparing. A connection opened on the file server, but after a couple minutes of preparing it released the connection and the backup failed complaining about it being locked still. I restarted AFP on the server, then the user's backup succeeded.

It seems like the file sharing service itself may be holding the lock. I'll try to look into it more when it happens again.

Reply