I've discovered a strange problem... if I have disk image files (DMGs) which reside on a read-only NFS share, I cannot open these in Mac OS X 10.7.5. The same files open fine when accessed over AFP. However, trying to open them using hdiutil attach when they're on the NFS share results in "attach failed - Read-only file system":

I don't have an NFS share to test with, but I would try to have a quiet system and run fs_usage to see if I can catch the filesystem making a write call - possibly filing a bug with Apple. It seems you should be able to read a read-only DMG - but perhaps there is some deeper technical reason why it's failing and the OS needs a better error message to inform us why...
–
bmike♦Nov 21 '12 at 15:04

Good idea @bmike! Also, I ran hdiutil with the -debug switch, I can post those logs here
–
JoshNov 21 '12 at 15:05

Indeed - make an answer with whatever you find and we can team up - report a bug or edit the answer as we pick apart the "why".
–
bmike♦Nov 21 '12 at 15:17

Which OS runs on the NFS server? What is the output of rpcinfo -p on the server? What is the output of mount on your Mac? Can you also add the relevant line of /etc/exports on the NFS server to the question?
–
jaumeNov 22 '12 at 9:04

1

I've set up an NFS server (Ubuntu 12.04) with a read-only export that I mounted on my Mac (OS X 10.8.2) and I couldn't reproduce your problem (I tested all dmg formats: readonly, compressed, encrypted, etc)... Could you add the output of hdiutil -debug and the information I asked for to your question?
–
jaumeNov 23 '12 at 21:07

2 Answers
2

I've been interested in this question since Nov 2012 and even set up a FreeNAS VM to reproduce the issue.

I eventually gave up but since the question has been resuscitated I will share what I found out back then and in the last hours (luckily I didn't delete the VM) and what I think the cause for this issue is. I have also found a workaround.

My setup

First of all, this is my test setup:

OS X 10.8.2 (sorry, no 10.7.5 around).

FreeNAS (FreeBSD 8.2-RELEASE-p1)

(The OP's version is FreeBSD 8.2-RELEASE-p7 - I couldn't find the same version.)

30 EROFS Read-only file system. An attempt was made to modify a file
or directory was made on a file system that was read-only at the time.

No surprise here, it is indeed a read-only filesystem, but... when mounted over AFP it works, why?

Because Apple's NFS implementation has some problems with locking. As stated in this post at gluster.org:

OS X does a phenominal amount of file locking (some would say,
needlessly so) and has always been really sensitive to the
configuration of locking on the NFS servers. So much so that if you
randomly pick an NFS server in a large enterprise, true success is
pretty unlikely.

5 EIO Input/output error. Some physical input or output error
occurred. This error will not be reported until a subsequent
operation on the same file descriptor and may be lost (over written)
by any subsequent errors.

which isn't suprising at all, the NFS filesystem was gone.

Workaround

A workaround (tested on OS X 10.8) is to mount NFS with options nolocks,locallocks. As explained in the post at gluster.org already mentioned:

Fortunately, there is a fix: just turn off network locking. You can do
it by adding the "nolocks,locallocks" options in the advanced options
field of the Disk Utility NFS mounting UI, but this is painful if you
do a lot of them, and doesn't help at all with /net. You can edit
/etc/auto_master to add these options to the /net entry, but it
doesn't affect other mounts - however I do recommend deleting the
hidefromfinder option in auto_master. If you want to fix every
automount, edit /etc/autofs.conf and search for the line that starts
with AUTOMOUNTD_MNTOPTS=. These options get applied on every mount.
Add nolocks,locallocks and your world will be faster and happier after
you reboot.

I manually mounted 172.16.54.186:/mnt/raid/netboot and it worked flawlessly:

Wow this is fantastic, Thanks! I will test this over the weekend, it might solve my issue!
–
JoshMar 15 '13 at 17:05

Thanks jaume, this worked like a charm! Unfortunately I have already found an alternative and no longer need to mount this same DMG with a shadow file, but nolocks,locallocks is helping NFS performance of other read-only NFS shares with DMG files, so thank you!
–
JoshMar 16 '13 at 12:49

Absolutely, and now I know what I need to change should I need this again in the future! (The goal previously was to place the /Library of our NetBoot image n a RAID array. We no longer need this as we purchased a new Mac Pro server)
–
JoshMar 18 '13 at 13:18

No, you misunderstand. I wanted to attache a read-only image as a read-write volume with a shadow file.
–
JoshMar 17 '13 at 18:14

1

Regarding your edit, no, using both -readonly and -shadow would read from a shadow file but mount the image read-only. So for example it would allow you to read changes made to a shadow file without updating that shadow file. The issue was NFS locks as jaume discovered.
–
JoshMar 18 '13 at 13:17

A very neat explanation from @Josh – thanks! I'll leave this answer so that other readers don't make the same mistake as me.
–
Graham PerrinMar 19 '13 at 3:10