Auto-mount internal drive by non-admin user?
 

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?

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.

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?

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.

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

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

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?

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.

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.

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?
:)

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

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.

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?

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.