View Full Version : Auto-mount internal drive by non-admin user?

12-29-2013, 11:35 PM
My main user ID had admin status when I set up schedules for SuperDuper! to clone the single startup drive to an internal drive on my MacPro. Normally the other drive is unmounted: SD! was able to automatically mount/unmount the other drive before/after running.

For security, I demoted my everyday user account to 'normal' user status, but now my scheduled SD! runs fail because SD! can't find the backup volume. If I run the schedule manually (press 'Copy Now') then I am asked for the username/password for an admin user; on entering them, the disk mounts and the backup proceeds.

Outside of SuperDuper!, if I use Disk Utility to mount the backup volume, then I am asked for an admin's username/password. But there is no option to save the admin's password in the normal user's keychain (probably by design). So that does not help me have a scheduled backup run automatically.

Is there a way to do this other than run SD! in an account with admin status? Or, can I set up the schedules when logged into a separate admin account, and somehow get them to run automatically even when the machine is not logged into that account?

12-30-2013, 07:18 AM
Sorry, no - the user you're running under has to have the ability to mount and eject volumes if you want it to automatically mount and eject volumes.

12-30-2013, 09:36 AM
Thanks for explaining.

With fast user switching, can a SuperDuper! schedule set up by User 1 run when User 2 is logged in and visible (is that called 'in front'?), while User 1 is logged in but in the background? And how does admin status then come into play between the two as far as mounting/unmounting disks?

12-30-2013, 10:03 AM
No, as indicated in the Scheduling section of the User's Guide, the User 1 schedule will not run when User 2 is onscreen. Admin affects the user who is scheduled, not the user who is not.

12-30-2013, 12:11 PM
If you're backing up by schedule to a disk image on network-attached storage, do you also need to run SD! in an admin account to automatically mount/unmount the disk images? [I don't have one to try this].

12-30-2013, 12:16 PM
If you can open them to mount them in Finder, we should be able to do so too.

06-22-2014, 10:23 PM
I'm having this issue too, apologies for bringing up an old thread, I figured it is recent enough & covers the same ground…

My standard user account requires a password to mount the internal disks (Mac Pro with 10.9.3).

What I cannot understand is that I give SuperDuper! admin access (to the entire system) but it still cannot mount a disk without intervention? I guess this is sandboxing at work?

I have been looking for a group for 'mounting disks' so that I could at least add my user to that group, but I can't see one on OS X, any ideas?

I'd like to work around this issue, as it currently stands I have to be sitting at the computer to make scheduled copies work. I unmount the disk after each copy to avoid accidentally writing or working from that disk.

Is there any point in moving the SuperDuper! user cron jobs into roots crontab?

Perhaps a root cron job could 'su' to the admin user?

06-22-2014, 11:02 PM
You can't run as root, no. This is a sandboxing/lockdown thing, and unfortunately -- without suid-ing the executable, I don't know how to work around the problem.

06-23-2014, 12:01 AM
I thought that might be the case, it makes it impossible to leave this unattended for standard users.

I had to suid ChronoSync years ago to make it work, I kinda hoped we'd have progressed since the mid 2000's :(

Thanks anyway for the prompt reply.

06-23-2014, 12:28 AM
Can you think of any reason not to use …
/usr/sbin/diskutil mount MyDisk
In root's crontab before the SD! job runs?

Then check if SD! is still running before trying to eject
/usr/sbin/diskutil unmount MyDisk

Seems like a simple bash script run every 20 mins or so after the backup can take care of ejecting it?

What am I missing? Why is this a terrible idea?

06-23-2014, 07:35 AM
Is that better than using an admin account as your regular account? I don't think so, but it might work.

06-23-2014, 12:09 PM
I'm trying to solve this not just because it annoys me personally but because other family members on Macs in different locations need to have a backup system that doesn't any require user attention.

Getting them to use Time Machine was hard enough. This nagging for passwords is just a reason not to backup.

I could make their main user an admin, but I have already had to rebuild one Mac because of a botched 10.9 upgrade. Any way to prevent them from shooting off their own toes is a good idea IMO :)

I could leave the backup disk mounted, but one day they will forget what I tell them and save data to the wrong disk & they will end up losing data during a backup.

I'm pondering why I shouldn't build rsync with support for Mac metadata & just do the whole thing as root & ditch SuperDuper!. I'd rather not do that since Macs are supposed to be 'user friendly', but this is a restriction too far. I know you do a lot of testing and SD! has been reliable in the years I have used it, so 'going my own way' is a concern.

I realise you are working within Apples guidelines & it's security limitations and may be equally frustrated by it.

Thanks for your time Dave, I appreciate it.

06-23-2014, 12:15 PM
That's up to you, of course. As I said, though, you can set the command suid which will likely work, no?

06-23-2014, 03:11 PM
That's up to you, of course. As I said, though, you can set the command suid which will likely work, no?

I hope so :)

What part of SuperDuper! needs to be suid-ed?

Is it all the executables within SuperDuper!.app/Contents/MacOS/.

I currently have
ls -l /Applications/SuperDuper\!.app/Contents/MacOS/
-r-sr-xr-x@ 1 root admin 23888 22 Feb 21:12 SDAgent
-rwxr-xr-x@ 1 admin admin 185968 22 Feb 21:12 SDCopy
-rwxr-xr-x@ 1 admin admin 78192 22 Feb 21:12 SDDiskTool
-rwxr-xr-x@ 1 admin admin 22512 22 Feb 21:12 SDUtil
-rwxr-xr-x@ 1 admin admin 497056 22 Feb 21:12 SuperDuper!

admin:admin should be suffice for the owner and group except for SDAgent?

06-23-2014, 03:18 PM
I was thinking more along the lines of diskutil, which is what's doing the mounting. Or replacing diskutil with something that's suid-ed and calling out to the real one.

06-26-2014, 02:37 PM
I was thinking more along the lines of diskutil, which is what's doing the mounting. Or replacing diskutil with something that's suid-ed and calling out to the real one.

You have lost me there Dave in more ways than one.

I am not a programmer.
I can hack my way around some problems with shell scripts, fugly Applescripts or with dull edged open source tools…

OS X seems to ignore SUID with shell scripts (the tiny part of the Apple docs I could understand supported this).

I did try calling diskutil in a SUID'd script but I really can't see how that is safer than calling diskutil directly from launchd or cron as a privileged user. It didn't work anyway even with the full paths.

Frankly I don't know how to fix this issue, and it strikes me as a fragile solution (run something before & after your schedules to mount and unmount the disk and hope we don't step on each others toes).

When I give any application my admin password to manage my 'system wide' backups that includes mounting the required disk.

The current user's account type is irrelevant to me when I am capable of elevating inside the app to admin permissions for cloning an entire system.

CarbonCopyCloner mounts & unmounts disks on scheduled copies. I can set CCC up for my family and it should be fine.

It even runs with no user logged in at all! No nagging, just backups that actually have a chance of running. It has less granular scheduling but who cares if it works.

Sorry Dave, I have used and recommended SuperDuper! for years, but this situation is not suitable for me or anyone I know (everyone I know wants 'set & forget' - a risk I know, but that is how people think).

I recently upgraded from 10.6 to 10.9 and I decided to use a standard account, which is why I had assumed SD! was taking care of everything.

You & Mike Bombich are smarter than I am, see if he has any bright ideas to work around this, I do want to support you since you seem like a nice guy on various podcasts & in these forums :^)

Cheers & all the best.

06-26-2014, 03:27 PM
If you're happy with another solution, it sounds like that's the best way to go for you.