Time Machine - why won't it automatically mount?

[walkerhk]

So we've been hitting our heads against the wall the past few weeks while we work to get Time Machine working in JAMF. We're using a network share (NAS) to back up all of our endpoints (which currently is only around 25, but will be upwards of 100 once UAT is complete). We've had some luck, however one of our requirements is to hide the share from the GUI so users can't access it and open other users backups.

The following is the script we've put in JAMF:

mkdir /volumes/shared/
mount_afp -o nobrowse afp://username:password@servername/timemachine /volumes/shared

We can manually connect it and it works, and before using the -o nobrowse flag it seemed to work alright too.. Anyone have any suggestions or see something I am missing? We also use a similar script to mount an SMB share which is the Sophos distribution point (which we have on-premises), and it runs without a hitch.

Thanks!

[htse]

Could you elaborate on the purpose of the above two lines that you want to execute in the script?

Time Machine stores the location of the network mount, and calls that location, mounting and unmounting it automatically when it needs it.

[walkerhk]

The purpose is to mount the network share (NAS) with the folder containing our time machine backups. As we use an AD account to authenticate, we put the service account username and password into the script to automatically authenticate to avoid the user being prompted.

"-o nobrowse" is used to hide the share in order ot prevent users from accessing it, as it houses all of the users backups.

Lastly, we specify the pathway for time machine in a configuration profile to try to lock it and automate the process. For some reason though, while it mounts the hidden share (using the credentials), time machine says it still needs the username and password to mount, even with us running the script at every login.

[tkessler]

You can have Time Machine for each system encrypt the backups so they each require passwords for access, and then assuming your users will not have admin access, you can configure your Macs for Time Machine with a dedicated admin account. This will prevent your users from mounting Time Machine drives from other systems, and while they can access the drive for the current system, by not being admin they will only have access to their own files and not those of other users on the current system.

For this routine, you can use a uniform password for all systems, or set up a script to make passwords unique, but identifiable on a per-machine basis (ie, use the machine's serial number, or a serialized scheme like TMPassIMac1, TMPassiMac2, TMPassiMac3, TMPassMacBook1, etc.). You can then configure the mount_afp, hdiutil, and tmutil commands in a run-once script to mount the central backup location, create an encrypted sparsebundle with the appropriate volume name (ie, the current machine name) and desired password scheme (see here for doing this for time machine: http://chester.me/archives/2013/04/a-step-by-step-guide-to-configure-encrypted-time-machine-backups-over-a-non-time-capsule-network-share.html/), and then set the backup destination for the system to the AFP mount.

This approach can be set up in a netinstall image during installation, when you enroll the Mac in your MDM solution, or at any other time using a service like JumpCloud that supports distributing scripts to managed systems.

[walkerhk]

We've looked into encrypting back ups which we would like to do (if we can automate the process), however we are still looking into hiding the share from users. Unfortunately we don't have time to redo how we're deploying time machine at the moment (and it would take a while to get approvals- we are in the financial services industry working with banks who have strict regulations and pre-approved processes). Thanks for the feedback and suggestions though!

The above script I posted is still what we're planning on using, which I know is similar to what others have done to hide the mounted network share. Does anyone have ideas as to why the script/process isn't working the way it should? (meaning, it mounts the share but time machine doesn't back up to it - it seems to want us to authenticate a second time before it allows us to back up).

[htse]

I see, I think I understand your intent, however the approach doesn't really fit into how Time Machine works.

The Time Machine process, backupd runs is a system process, and runs as root, so it can reach into and backup the places that a user cannot.

When you setup a network share for Time Machine, it stores that location in /Library/Preferences/com.apple.TimeMachine.plist, and stores the credentials in the System Keychain. When the Time Machine performs it's backup or when the user launches Time Machine, it pulls the location it knows about and strings it together along with the login stored in System Keychain, to automatically mount the network share, and it's associated backup image and unmount both when it is done.

So running the login item at the user level and passing -nobrowse wouldn't work. It may potentially work if it runs as root, but the way I would see it, permanently mounting the share at login leaves it more exposed. I would agree with @tkessler, if you're using a shared network share, you would need to encrypt the backup, if you're looking at user separation using a shared network space.

tmutil should allow you to automate the Time Machine configuration
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/tmutil.8.html

[walkerhk]

Thanks for the responses, sorry for posting back here over a week late! We will be encrypting back ups to protect them as they are in a shared location. Thank you for the feedback!

Unfortunately over last weekend we ran into a new issue... Using the common username/password in the script to mount the NAS volume for backups has worked well (and we were able to hide the share from the user), except after a week of backing up multiple machines, all backups disappeared off of the NAS - twice. Is this because we aren't using individual AD credentials, or is this a fluke?

We did not realize how much of a headache time machine is. We will eventually have around 100 users backing up to this NAS location beginning in January, and we can't afford for backups to periodically be erased.. Hoping this was a random occurrence, but trying to see if our authentication method is causing issues.

If anyone else is using time machine and NAS at this wide of a scale, please let us know if you have any other insight.