I've had Time Machine set up on my OSX Server for quite a while, but now that I upgraded my USB storage I can't seem to connect to the server. When I go to Time Machine preferences and click Select Backup Disk... I can see the share as usual. After I select the drive, turn on encryption and click Use Disk, I get asked for my credentials. If I enter the wrong credentials, the dialog shakes as it's supposed to, but when I enter the correct username and password, I'm thrown back to the disk selection screen.

I've tried turning the Time Machine service on and off, removing and adding the backup location to the service, deleting /Library/Preferences/com.apple.TimeMachine.plist on the client, but every time the same happens. No info can be found in the console on the client, and the only possibly related lines on the server are from kdc regarding encryption and this line: 26/06/17 23:24:04,130 AppleFileServer[25122]: Logged out 0x7f86da033600.

Any ideas would be appreciated. Screenshots here.

Almost forgot: the client is running 10.12.5, and the server is 10.10.4.

2 Answers 2


This happens with the user does not have permission to write to the share. You can verify this by connecting to the share in the normal way and trying to copy a file to it. The copy will not be allowed, conveyed by the mouse pointer changing to a no-entry sign. To fix, run the Server app and go to the File Sharing section and select your backups share. Then click edit (the pencil) and change "Everyone Else" to Read & Write (see screenshot). Now you will be able to successfully copy a file to the share and also the Time Machine setup problem will be fixed.File Sharing Screenshot

You would think that the Permissions for Backup Service ACL (also shown in screenshot) would take into account the users selected in the Time Machine section but it didn't in my case. Perhaps after adding a new user you need to restart File Sharing or reboot the server then maybe it would work without requiring this extra setting but I haven't tried it.


I just had the same experience that I solved by deleting the sparseimage on the server and the client was then able to create a new backup. I did not examine the ownership/permissions settings of the old image, but perhaps that was the issue as mentioned by melhal.

Renaming or moving the old sparseimage would allow the client to create a new backup while safely retaining the old backup for a while would be a "safer" proceedure, but I have other backups to rely on for some history until the new backup is completed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .