Auto-mount internal drive by non-admin user?

[Michael@wengam]

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?

[dnanian]

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.

[Michael@wengam]

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?

[dnanian]

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.

[Michael@wengam]

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

[dnanian]

If you can open them to mount them in Finder, we should be able to do so too.

[Droid]

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?

[dnanian]

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.

[Droid]

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.

[Droid]

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?

[dnanian]

Is that better than using an admin account as your regular account? I don't think so, but it might work.

[Droid]

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.

[dnanian]

That's up to you, of course. As I said, though, you can set the command suid which will likely work, no?

[Droid]

Originally Posted by dnanian

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?

[dnanian]

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.