6 Replies Latest reply: Aug 13, 2013 3:53 AM by georgi0
matt68000 Level 1 (0 points)

I have a disk image "backup_image.sparsebundle". If I go to the terminal on my machine and type "open backup_image.sparsebundle" the disk image mounts as expected. No problems. If I secure shell (ssh) log in from a remote Mac and execute the same "open backup_image.sparsebundle" a warning dialog pops up and states that "The following disk images couldn't be opened" followed by my disk name. This is incredibly odd because it used to work just fine. I didn't think there were any ACL differences between a local terminal shell and remote ssh. I mean a shell is a shell right? Or, it used to be and now it isn't? I'm not doing anything obviously incorrect (to me); I'm the same user locally and remotely, same path to disk image. This used to work fine before Mountain Lion.


Background: All of this started because I wrote a script that would ssh in to a remote machine, open the disk image on that remote machine, mount it across the network over afp and rsync. If I leave the disk image mounted on the remote machine, the script runs fine but if the image is close and I try to remotely open the image as I always did, it fails. The only thing that has changed in the system is, now, both machines are running Mountain Lion. Odd.



MacBook Pro, OS X Mountain Lion (10.8.2)
  • surogat70 Level 2 (150 points)

    Maybe this is the root of the problem? -> http://support.apple.com/kb/HT4700

  • matt68000 Level 1 (0 points)

    That second paragraph in my original post is a bit of a distraction. The issue is not with AFP, that part works fine. The issue is with mounting the disk image with "open backup_image.sparsebundle". The DiskImageMounter.app launches as a result of that command whether I'm on a terminal session on the actual machine or secure shell. The difference is in a local session the disk image mounts but from a ssh session, it does not.


    I verified this without actually being remote just now. If I open a terminal session and then "ssh localhost" and secure shell in to my own machine and try to open the disk image, it fails in the same manner. DiskImageMounter.app does not like being executed from a ssh session.


    [user:~] user: who

    computer_name console  Oct 18 00:17

    computer_name ttys000  Oct 28 12:32       <---- ttys000 can open the disk image

    [user:~] user: ssh localhost

    Last login: Sun Oct 28 12:32:55 2012

    [user:~] user: who

    computer_name console  Oct 18 00:17

    computer_name ttys000  Oct 28 12:32       <---- ttys000 can open the disk image

    computer_name ttys001  Oct 28 12:33           (localhost)          <---- ttys001 can NOT open the disk image

    computer_name ttys002  Oct 28 12:35        <---- ttys002 can open the disk image



    I combed /private/var/log/eventmonitor and system.log but nothing appears (which is odd, system.log usually has too much info).

  • surogat70 Level 2 (150 points)

    Have you every tried using hdiutil for the purpose of mounting images via command line?

  • matt68000 Level 1 (0 points)

    Great idea but there is a wrinkle in the plan. My disk images are password protected (encrypted). Using the "open" causes DiskImageMounter.app to launch and, since the password is stored in the keychain and always approved, I never have to enter the password so long as the image is mounted on the correct machine. I prefer that layer of security even though it is arguably flawed. If I open with hdiutil, it asks for the password and my script to synchronize goes from being automated to requiring interaction to enter the password. -stdinpass could work but then I'd have to store the password clear text in the script. I'll see if I can sort something out with -recover or "secuirty".


    Odd that if I do "hdiutil attach backup_image.sparsebundle" on the local machine, it mounts without asking for the password but if I do it from a ssh session, it does ask.


    The same goes with if I try to programatically get the password from the keychain with:

    security find-generic-password -w -D "disk image password" -l backup_image.sparsebundle


    If I'm local, it spits out the password, no problem. If I ssh in, no luck.



    security find-generic-password -w -D "disk image password" -l backup_image.sparsebundle | hdiutil attach backup_image.sparsebundle

    This works locally just fine but again, hosed if I try it remotely


    I suppose the solution is to store the password in they keychain of the computer trying to issue the remote command, programatically retreive it from that keychain in to a script variable and send it through the network?


    Thanks for the idea though!



  • matt68000 Level 1 (0 points)

    Storing the password for the remote disk image in the local keychain of the computer running the script (in to a variable), then passing it accross to the remote machine worked. I'm not sure why all of this changed moving from Lion to Mountain Lion but I suppose it is slightly more secure.


    To programatically mount and sync a remote encrypted disk:




    if [ -n "`mount | grep ~/sync`" ]; then

      echo "Already mounted"


      pw=$(security -v find-generic-password -w -D "application password")

      ssh -o ConnectTimeout=1 user@xxx.xxx.xxx.xxx "echo $pw | hdiutil attach /Users/user/backup_image.sparsebundle"

      mkdir ~/sync

      mount_afp -s "afp://matdup01:Armbwan1@ Image" ~/sync



    if [ $? -eq 0 ]; then

      echo "Mount succeeded!"


      echo "Mount Failed"

      exit 0



    rsync -vrxtu --delete-before --exclude _* "/Volumes/Media/new Media/" ~/sync/new\ media/


    umount ~/sync

    rmdir ~/sync


  • georgi0 Level 1 (0 points)

    Syntax Error:

    Screen Shot 2013-08-13 at 1.51.17 PM.png


    can you help?