3 Replies Latest reply: Nov 15, 2014 9:42 PM by Warwick Teale
tArre Level 1 Level 1



I'm on the way to prepare a diskless netboot in OS 10.7.2.


Everything seems ok. I've made the image, tag it as diskless, default, and the client boots.


When i run "mount" in the client after boot and sucessful login i get this:


tarrero-mac:~ root# mount

/dev/disk2s2 on / (hfs, local)

devfs on /dev (devfs, local, nobrowse)

afp_3ubSFX2uPHUn2ArKAf0wlyRV-1.2c000002 on /private/var/netboot (afpfs, nobrowse)

/dev/disk1s6 on /private/var/netboot (hfs, local, nodev, nosuid, journaled)

/dev/disk0s2 on /Volumes/Macintosh HD (hfs, local, journaled)

map -hosts on /net (autofs, nosuid, automounted, nobrowse)

map auto_home on /home (autofs, automounted, nobrowse)

map -fstab on /Network/Servers (autofs, automounted, nobrowse)

afp_3ubSFX2uPHUn2ArKAf0wlyRV-1.2c000006 on /Network/Servers/ichigo.dammz.com/Volumes/RAID1/Users (afpfs, nodev, nosuid, automounted, nobrowse, mounted by daniel.tarrero)

afp_3ubSFX2uPHUn2ArKAf0wlyRV-1.2c000007 on /Volumes/Users (afpfs, nodev, nosuid, mounted by daniel.tarrero)

/dev/disk1s2 on /Volumes/OS1 1 (hfs, local, nodev, nosuid, journaled)

/dev/disk1s4 on /Volumes/OS1-2 (hfs, local, nodev, nosuid, journaled)

/dev/disk1s5 on /Volumes/OS3 (hfs, local, nodev, nosuid, journaled, noowners)


I have two physic drives plus one (netboot).

disk0 is my internal drive (with "Macintosh HD" and "Recovery" partitions), and disk1 is a firewire drive (with "OS1", "OS2", "OS3" and "Data" volumes).

disk2 (i guess) is the netboot volume.


Please pay special attention to the two bold lines.


From the first one (correct me if i'm wrong) i know the machine is "netboot'ing"


The weird comes with the second bold line, where one of my local drives is getting mounted in the same path!!!


From this great but outdated document (Troubbleshooting the netboot process), i learn that in this mount point there should be the "shadow" volume mounting, not any local drive.


Some interesting checks looking for the proper answer in DHCP packets:


tarrero-mac:~ root# ipconfig netbootoption shadow_mount_path



tarrero-mac:~ root# ipconfig netbootoption shadow_file_path



tarrero-mac:~ root# ipconfig netbootoption machine_name



Everything seems ok.


If i try to manually mount the shadow volume...

Let's say, CMD+K -> afp://netboot100:272b57d9@


... that mounts the volume propperly, with write permissions.



In fact, there is a folder in the network shadow volume called "NetBoot001" with a file inside called "Shadow" (binary file, around 50Mb, wooow!)

So the machine connects to the folder and creates the files needed.


While almost all local disk mounts in the right place (/Volumes/*), there is always one partition which mounts in the Shadow drive mount path.

In the logs before, it was the "Data" volume whithin "disk1s6".


If i physically remove some of this local drives (let's say the firewire one, which s6 partition actually is mount in /private/var/netboot), the partition which get mounted in this place changes too! after that, it was the "Macintosh HD" (disk0s2) which get mount in this wrong place (so it's not an UUID related problem, neither fstab-like systems, i guess).



I've also made a test in the Netboot Image. I've editted the netboot boot process in /etc/rc.netboot to force (and check if fails) the shadow mount:




# Purpose:

#   To change the behavior of the system when choosing a netboot shadow

#   to use.

# Values:

#   -NETWORK-           Try to use the network for the shadow file, if

#                       that fails, use the local drive

#   -NETWORK_ONLY-      Only use the network, fail if not available

#   -LOCAL-             Use the local drive for the shadow file, if that

#                       fails, use the network

#   -LOCAL_ONLY-        Only use the local drive for the shadow, fail if

#                       not available









... and this also work, forcing the shadow to be "Network only, if not fail", so i define my problem as:


Regardless the shadow mount is working as expected and properly configured, some ¿random? partition from local drives get mount in it's mounting path.




Someone knows how to fix that?

Someone knows what problems derive from a missworking shadow volume?

Someone points me to where can i make some more tests or debug?


thanks and regards! and excuse that "homemade" english, i hope you to understand

Xserve, Mac OS X (10.7.2)
  • Joel Bruner1 Level 1 Level 1

    I had this problem, ended up being I added the NetBootClients0 group to have Read/Write permissions on /Library/Netboot/NetBootClients0 and propagated the ACL permissions. Which is the same effect of setting Everyone to Read/Write UNIX-wise, since the group NetBootClients0 included Everyone.


    Anyway, that's what it was, the netboot client didn't have permissions to write to the share so if fell back to the local storage. Might have something to do with using HTTP vs. NFS I wonder?


    Anyway, that did it.

  • Joel Bruner1 Level 1 Level 1

    Actually that did not do it permanently, permissions on new Shadow files created by Server asre incorrect until a couple client reboots, then they are fixed...


    Filed a bug with Apple this morning also mirrored here: Open Radar 13937874

  • Warwick Teale Level 3 Level 3

    HI TArre, I came across you post these past days whilst trying to resolve the same issue. I have resolved this now by using some information similar to what you and Joel have posted and additional from other varied sources not only OSX.

    I have detailed a procedure at https://discussions.apple.com/thread/6039524


    For others having the issue of not being able to DISMOUNT UNMOUNT direct attached file systems when in NetBoot Diskless mode because one is in use for /private/var/netboot part of the cause is certainly the inability of AFP to access AND be authorised for READ/WRITE of the volume/folder for Netbootclients0 (1,2,3 etc) over AFP. Any readers here , I suggest you check that first .

    Use the following osx ipconfig (yes!) commands to verify the AFP path from the net booted client.


    verify the APF netboot shadow file path its trying to use - use Terminal

    ipconfig getpacket en0

    sudo ipconfig netbootpacket


    Sadly there is not much in the way of textual diagnostics in the NETBOOT process.

    Post your results for others to see.



    Hong Kong