0

[macOS Mojave 10.14.6]

I've recently discovered r/w disk images and the particularly fascinating sparse bundle.

As I understand it, an image (the .dmg or .sparsebundle itself) is "attached" and "detached" much the same as an external drive, for example, would be "plugged in" or "unplugged." The volumes contained in either case would then be "mounted" and "unmounted." But here's the problem:

caffeinatedbits ~$ hdiutil create -size 1g -layout GPTSPUD -fs APFS -volname temp -type SPARSEBUNDLE -nospotlight -encryption AES-256 temp.sparsebundle
Enter a new password to secure "temp.sparsebundle": 
Re-enter new password: 
created: /Users/caffeinatedbits/temp.sparsebundle
caffeinatedbits ~$ 
caffeinatedbits ~$ hdiutil attach temp.sparsebundle -mountroot .
Enter password to access "temp.sparsebundle": 
/dev/disk8              GUID_partition_scheme           
/dev/disk8s1            Apple_APFS                      
/dev/disk9              EF57347C-0000-11AA-AA11-0030654 
/dev/disk9s1            41504653-0000-11AA-AA11-0030654 /Users/caffeinatedbits/temp

I noted here that attaching the image apparently auto-mounts the volume. Cool.

I figure maybe it would do the same in reverse, but when attempting to detach the image, it only ejects the volume:

caffeinatedbits ~$ hdiutil detach temp
"disk9" ejected.
caffeinatedbits ~$ diskutil list | grep disk8
/dev/disk8 (disk image):
   0:      GUID_partition_scheme                        +1.1 GB     disk8
   1:                 Apple_APFS Container disk9         1.1 GB     disk8s1
                                 Physical Store disk8s1

The image itself (/dev/disk8) remains attached and must be detached separate from the volume itself (previously /dev/disk9s1).

At this point, I began to wonder if it's safe to rsync/backup the image since it's still attached? Or could that cause corruption? So I wanted to figure out how to completely detach the image...

caffeinatedbits ~$ hdiutil detach disk8
"disk8" ejected.

Then I wondered if I could've just done that in the first place. As it turns out, I can...

caffeinatedbits ~$ hdiutil attach temp.sparsebundle -mountroot .
Enter password to access "temp.sparsebundle": 
/dev/disk8              GUID_partition_scheme           
/dev/disk8s1            Apple_APFS                      
/dev/disk9              EF57347C-0000-11AA-AA11-0030654 
/dev/disk9s1            41504653-0000-11AA-AA11-0030654 /Users/caffeinatedbits/temp
caffeinatedbits ~$ hdiutil detach disk8
"disk8" ejected.

But then I wondered whether damage could be caused to the volume since it wasn't first unmounted. Should I unmount the volume first, or does detaching the image (disk8) do that automatically?

caffeinatedbits ~$ hdiutil attach temp.sparsebundle -mountroot .
Enter password to access "temp.sparsebundle": 
/dev/disk8              GUID_partition_scheme           
/dev/disk8s1            Apple_APFS                      
/dev/disk9              EF57347C-0000-11AA-AA11-0030654 
/dev/disk9s1            41504653-0000-11AA-AA11-0030654 /Users/caffeinatedbits/temp
caffeinatedbits ~$ umount disk9s1
caffeinatedbits ~$ hdiutil detach disk8
"disk8" ejected.

Anyone know why calling hdiutil detach <mountpoint> doesn't detach the image? I figure it's because only the volume (disk9s1) is mounted to that mountpoint and it just stops there.

Once detached, I'm using rsync -ai --inplace image.sparsebundle -e ssh u@x.x.x.x::share/ to backup the image to my NAS. As I understand it, it's a very bad idea to do this while the volume is still mounted, but what about the image itself remaining attached? Does it matter?

What is the proper way to do this to ensure I don't corrupt my images?

Update @Gordon Davisson

caffeinatedbits ~$ hdiutil attach temp.sparsebundle -mountroot .
Enter password to access "temp.sparsebundle": 
/dev/disk8              GUID_partition_scheme           
/dev/disk8s1            Apple_APFS                      
/dev/disk9              EF57347C-0000-11AA-AA11-0030654 
/dev/disk9s1            41504653-0000-11AA-AA11-0030654 /Users/caffeinatedbits/temp
caffeinatedbits ~$ cd temp
caffeinatedbits temp$ hdiutil detach disk8
hdiutil: couln't unmount "disk8" - Resource busy
caffeinatedbits temp$ cd ..
caffeinatedbits ~$ hdiutil detach disk8
"disk8" ejected.

Based on your comment, I guess this shows that the volume is unmounted by detaching the parent image?

1
  • I don't have a Mojave system handy to test with, but a couple of things occur to me: try cding into the mounted volume, then detaching the /dev entry, and see if having the directory open prevents it from unmounting; if it does, that indicates it's doing a proper unmount. Also, try detaching the mount point of an HFS+ formatted image -- in the past, that took care of everything, so I'm wondering if the change is due to APFS, or if this is just the way hdiutil works these days. – Gordon Davisson Mar 17 at 21:32
1

The man page for hdiutil(1) states

 detach dev_name [-force]
            detach a disk image and terminate any associated process.  dev_name is a partial /dev node path (e.g. "disk1").  As of Mac OS X 10.4, dev_name can also be a mount-
            point.  If Disk Arbitration is running, detach will use it to unmount any filesystems and detach the image.  If not, detach will attempt to unmount any filesystems
            and detach the image directly (using the `eject' ioctl).  If Disk Arbitration is not running, it may be necessary to unmount the filesystems with umount(8) before
            detaching the image.  eject is a synonym for detach.  In common operation, detach is very similar to diskutil(8)'s eject.

So the recommended way to detach would be to simply pass the mountpoint. I’ve tested this on Catalina and it works for me. Here is the transcript:

1. Creating the image and reviewing the automounted volume

% cd ~/Desktop 

% hdiutil create -size 1m -layout GPTSPUD -fs APFS -volname temp -type SPARSEBUNDLE -nospotlight -encryption AES-256 temp.sparsebundle
Enter a new password to secure "temp.sparsebundle": 
Re-enter new password: 
created: /Users/pion/Desktop/temp.sparsebundle

% mount
[...]
/dev/disk5s1 on /Volumes/temp (apfs, local, nodev, nosuid, journaled, noowners, mounted by pion)

% diskutil list
[...]
/dev/disk4 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +1.0 MB     disk4
   1:                 Apple_APFS Container disk5         1.0 MB     disk4s1
/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1.0 MB     disk5
                                 Physical Store disk4s1
   1:                APFS Volume temp                    41.0 KB    disk5s1

2. Unmounting the automounted volume

% hdiutil detach /Volumes/temp 
"disk4" ejected.

% mount
[...]

% diskutil list               
[...]

3. Mounting onto Desktop mountroot

% hdiutil attach -mountroot . temp.sparsebundle
Enter password to access "temp.sparsebundle": 
/dev/disk4              GUID_partition_scheme           
/dev/disk4s1            Apple_APFS                      
/dev/disk5              EF57347C-0000-11AA-AA11-0030654 
/dev/disk5s1            41504653-0000-11AA-AA11-0030654 /Users/pion/Desktop/temp

% mount
[...]
/dev/disk5s1 on /Users/pion/Desktop/temp (apfs, local, nodev, nosuid, journaled, noowners, mounted by pion)

% diskutil list
[...]
/dev/disk4 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +1.0 MB     disk4
   1:                 Apple_APFS Container disk5         1.0 MB     disk4s1

/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1.0 MB     disk5
                                 Physical Store disk4s1
   1:                APFS Volume temp                    24.6 KB    disk5s1

4. Unmounting from Desktop mountroot

% hdiutil detach temp
"disk4" ejected.

% mount
[...]

% diskutil list
[...]

Incidentally, if you were curious why you get both a disk8 and disk9 instead of just disk8, it's because you're using APFS. disk8 is the new disk you've just created (as a disk image) and mounted. disk8s1 is its first (and only) partition, formatted as APFS. The way that APFS works is by creating its own container that covers an entire partition and then mounts it as a separate virtual disk (disk9) which can then have its own virtual partition (disk9s1).

6
  • 1) I am pretty sure you are incorrect. Option "-mountroot" sets the root of the mountpoint. By using "-mountroot ." from my home directory, the image is attached, and the volume is mounted to "~/<image_name>" (in my case, "~/temp". I think you confused the "-mountroot" option with the "-mountpoint" option. Using "-mountpoint ." would indeed remount my home directory as you said. 2) You are also incorrect about calling "detach path/to/mountpoint". That only unmounts the volume (in this case, disk9s1), while disk8 (the parent container/image) remains attached, as illustrated above. – caffeinatedbits Mar 18 at 4:54
  • P.S. the reason for using my home directory as the -mountroot is because I want it hidden from other users. Without specifying a -mountpoint (or as I've illustrated, -mountroot), the image is attached and its volume is mounted to /Volumes (as you said above). However, if you go ahead and try that, then switch users, you will notice that your volume is likewise accessible to any other user. By mounting in a user's home directory, it prevents other users from accessing it (as far as I can tell, anyway.. at least I can't just open it up in Finder as another user this way). – caffeinatedbits Mar 18 at 4:57
  • @caffeinatedbits You are correct on the -mountroot vs. -mountpoint distinction; I was careless in my own reading of the man page! I’ll update my answer. Nevertheless, the man page was clear about the common usage pattern for detaching. I’ll copy my own test into my answer. Note that I am doing this on Catalina and it’s possible that the behavior has changed since Mojave. Given the man page’s description of behavior, you may be encountering a bug that’s been resolved in later versions of macOS. – pion Mar 18 at 5:58
  • Follow the steps I did above. See whether it actually detaches the parent image (disk8 in my case) or just the volume (disk9s1 in my case) if you hdiutil detach path/to/mountpoint. I have seen other forums where Catalina users experience the same issue. It's not necessarily a bug, but rather it could be bad if macOS just started detaching disks because a single volume was unmounted. My question was more about the correct way to detach a disk -- whether the volume should be unmounted prior to detachment. – caffeinatedbits Mar 18 at 6:07
  • Excellent, well researched and detailed answer -- thank you for your contribution. I would definitely give you an upvote (I cannot, too new to Ask Different) and mark it as accepted if I could, however Mojave does not appear to behave the same way as Catalina. As such, I will leave my question open for now in the hope that someone can shed some light on the differences. – caffeinatedbits Mar 18 at 6:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .