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?
|
Quote:
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.
|
Quote:
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. |
If you're happy with another solution, it sounds like that's the best way to go for you.
|
All times are GMT -4. The time now is 04:29 AM. |
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.