Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

With sparseimage files, I can set the Locked attribute in 'Get Info' to prevent modifying its content. Doing so with sparsebundles has no effect it seems.

At the moment I'm storing my sparsebundle inside of a sparseimage to get this easy-lock functionality.

Am I overlooking an easier way of making my sparsebundle volume read only?

share|improve this question
up vote 4 down vote accepted

It seems Finder does not apply the Locked flag (or permission changes in the Get Info dialog for that matter) recursively for the entire bundle. If this is something you regularly need, you might want to look into writing a service for the following suggestions, so you can do this from Finder instead of the Terminal.

You can remove write permissions to the bundle on the command line by running chmod:

chmod -R a-w 

Type this command (including a trailing space character), then drag the icon for the sparse bundle onto the Terminal window. It should look like this, depending on the name of your sparse bundle and where it's stored:

chmod -R a-w /path/to/container.sparsebundle

Run chmod -R u+w /path/to/container.sparsebundle to get write permissions again. These commands may take a while for large sparse bundles.

Alternatively, you can set the locked flag on all files in the bundle by running the command chflags:

chflags -R uimmutable /path/to/container.sparsebundle

To revert, run chflags -R nouimmutable /path/to/container.sparsebundle.

You can always mount the bundle read-only as well, to only temporarily prevent changes. To do this, run the following in Terminal:

hdiutil attach /path/to/container.sparsebundle -readonly

Note that you will need to always mount it like this to prevent changes.

If you can tolerate the image using a different mount point than usual, you can run configure your system to always mount this image read-only.

First, determine the volume UUID. Mount the sparse bundle, and run diskutil list on the command line. Look for an entry with the same name as your volume, like the following:

   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        *102.4 MB   disk8
   1:        Apple_partition_map                         32.3 KB    disk8s1
   2:                  Apple_HFS Disk Image              102.4 MB   disk8s2

In this example, the volume shows up as "Disk Image" in Finder. Note the identifier on the right (disk8s2). You need to enter it for the following command after /dev/:

diskutil info /dev/disk8s2

Look for the line that starts with Volume UUID, and note the value to its right, e.g. D7C6180C-2178-32EF-98E6-7FB71AED2ABC

Now we just need to create a custom mount point. Usually, every volume is mounted in /Volumes, but those mount points are deleted when unmounting, and the next mounting attempt of a volume referenced in fstab will fail because the mount point doesn't exist. So just create a folder named "Image" in your home directory.

Now we can OS X to always mount it read-only. In Terminal, run sudo vifs and enter your password. I assume you're familiar enough with vi/vim, if not, now's a good time to read up on it.

Add a line like the following, substituting the correct values for UUID and mount point applicable to your system:

UUID=D7C6180C-2178-32EF-98E6-7FB71AED2A56 /Users/danielbeck/Image hfs ro

Then save and close. Now you can mount the image with a double-click, it will show up in Finder, and will be read-only.

share|improve this answer
Wow, thanks for this thorough reply! In principal, what do you think of my storing the sparsebundle in a sparseimage which I can lock? I'm using a sparsebundle so i can incrementally backup changes to a networked volume. Is there some danger i'm overlooking in doing this? – noop Jan 29 '13 at 14:21
@noop This depends on your use case. There might be issues with CPU usage, as you're going through two layers of virtual disks instead of one. Additionally, you need to make sure the sparse image always matches the bundle in terms of size limit (and the related partition map when going >2TB) when modifying the sparse bundle contents. If you're changing the image contents a lot, compacting (i.e. recovering disk space currently unused in the sparse bundle) will be more effort due to the nested nature of your solution. – Daniel Beck Jan 29 '13 at 14:31
i can't decide now between continuing with my sparseimage/sparsebundle approach, or using hdiutil -readonly. thanks anyway for your insights. – noop Jan 29 '13 at 14:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.