Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Create a more dynamic fstab using UUIDs UNIX
Finding myself frustrated with OS X's attitude toward disk mounting, I had created an fstab file per the instructions in a previous hint: i.e.:
LABEL=Apps  /Applications hfs 1 2
Digging through the various man pages (many outdated or for missing programs like getmntent, others), I kept seeing references to Unique Universal Identifiers, UUIDs. These would allow an fstab not dependent on disk names, but instead would be able to recognize this 16-digit string, thus allowing more Mac-like freedom.

A Disclaimer: This is probably something to be careful about, make sure typos are watched for ... I had to boot up without my home directory, and many things were thus temporarily broken until I fixed one little error in the uuid for this drive. Be sure that you record the uuids the first time you see them, it becomes annoying to mount and unmount drives more than necessary to get the uuids.
please be sure to back up any critical or important data
[robg adds: I couldn't agree more, and I have not tested this one (nor do I have any plans to do so!), so please, proceed with caution...]

Then I tried to figure out how. After an hour or so of google mining, I finally discovered a few quick commands which would make this possible. Step one, possibly easy, possibly hard -- unmount the drives you wish to enter in as UUIDs instead of LABELs in the fstab. To determine device names, use disktool -l to print a list. pdisk disk n -dump works as well; replace n with the number a given drive is supected to be. The latter method is quicker, but less pure on some higher level, be quite assured.

Once these drives are unmounted, type:
 % /System/Library/Filesystems/hfs.fs/hfs.util -s devicename
Replace devicename with the disk ID, for example, disk0s10. This command apparently adds a UUID to the drive. The next step, though easily typed, can be finicky (reasons unknown). Type:
 % /System/Library/Filesystems/hfs.fs/hfs.util -k device > ~/file_to_store_uuid_in
Once this has been done for each drive which is to be referenced by UUID, use the terminal to open the fstab file (sudo pico /etc/fstab works well, vim, whatever you feel comfortable with) and either add or replace existing entries with the format:
UUID=16-character uuid /mountpoint filesystem 1 2
Replace "16-character uuid," "mountpoint," and "filesystem", of course, with the appropriate data. Filesystem is most likely hfs, unless it is a CD-ROM you are referencing, a Winpod, or any other non-Mac-only device.

Once all new entries have been added, and conflicting entries removed, NetInfo must be informed. This is accomplished in the same way Numbski described: Type sudo niload -m fstab /. Alternately, a reboot is equally effective though much less efficient. I have found that using Numbski's SetFile -a V filename tricks are effective, but another method, now that we are liberated from being tied to the staticicity of a name, is simply adding a period to the beggining of its name. The period in front is aesthetic, quick, and the UNIX way of doing things. Sometimes, though, the Finder ignores this, so I tend to use both if I want a volume to not show up in the Computer level of Finder windows:
 % diskutil rename device newname
(Replace "device" and "newname" with the proper values). This is a quick command-line shortcut to renaming drives.

If a drive does not appear, make sure you had a folder already existing at the mount point, that you typed everything properly -- make sure that you haven't actually mounted it! df -k will reveal which drives are mounted and what amounts of space they possess. Using disktool -l again to see what's going on can be, of course, supplemented by df -k and ls -fal | less to snoop around and determine the cause. Altogether, it took me three or four reversible failures to get it right. Don't give up!
    •    
  • Currently 2.60 / 5
  You rated: 2 / 5 (5 votes cast)
 
[42,675 views]  

Create a more dynamic fstab using UUIDs | 22 comments | Create New Account
Click here to return to the 'Create a more dynamic fstab using UUIDs' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Create a more dynamic fstab using UUIDs
Authored by: nvdingo on Mar 04, '03 12:28:04PM

I am not clear on why someone would want to do this. I am sure there is a reason, but the article provides none.



[ Reply to This | # ]
Create a more dynamic fstab using UUIDs
Authored by: rorya on Mar 04, '03 02:02:22PM

As the author mentions, it gives more flexibility. Using this method would still allow your Mac to mount static mount points, even if you decide to rename the filesystem. UUID, as mentioned, gives the drive a unique ID so it proves to be a more reliable method. I believe, since this information is stored within the slice, you can use this same ID on a different system. So, you could move the drive to a new system and still expect the UUID to work correctly. Most modern Linux distributions and probably other unix-like OSs support this feature now.

---
"Any sufficiently advanced technology is indistinguishable from magic" - Arthur C. Clarke



[ Reply to This | # ]
Create a more dynamic fstab using UUIDs
Authored by: theNonsuch on Mar 04, '03 01:41:33PM

My guess is that, at the moment, OS X mounts volumes in fstab by looking at the actual volume label (the name of the volume), so if you rename a fstab mounted volume to something else, it won't mount anymore. This hint works around that by binding to a deeper system-level name.

At least that's what I think this hint is referring to. I stopped using fstab to mount volumes when I started getting mount errors on startup.



[ Reply to This | # ]
Error with the NetInfo mounts import command line
Authored by: rorya on Mar 04, '03 01:57:45PM

I've noticed that the command line mentioned for loading the contents of fstab into NetInfo's /mounts is incomplete. The way it is specified in the article would not work. It's important as it's a crucial step in the process. Here is the right command:

% sudo niload -m fstab / < /etc/fstab

As you may have noticed, the " < /etc/fstab" is missing in the article's directions command line example.

---
"Any sufficiently advanced technology is indistinguishable from magic" - Arthur C. Clarke



[ Reply to This | # ]
Why do this? Well....
Authored by: Numbski on Mar 04, '03 04:25:39PM

I can see one good use already. :P

Let's say I've got a pocket usb drive, or even a firewire drive that I wanted to mount into my home directory when I'm logged in. I could now do this by UUID, and as my use of the drive changed (say it was named MP3 at one point, then I started using it for OGG instead) I could rename the drive as I saw fit, and it would still into the correct location on my machine, but show up with a useful name on anyone else's.

Very slick indeed.



[ Reply to This | # ]
rant
Authored by: a1291762 on Mar 04, '03 05:14:11PM

Since fstab doesn't work as a Unix admin would expect, Apple needs to provide a method of configuring mounts from their GUI.

All I really want to do is add a /dev/disk0s10 /Stuff line to my fstab but that doesn't work. Actually, since I have 10.1 fstab doesn't work at all. The Label=blah that 10.2 has isn't really an improvement.

I actually preferred the Public Beta's mounting drives in / since it made for shorter paths when accessing things from the console.

I think it would be nice if Apple made a folder of /System the root directory (I don't think this can be done presently). That way, all "volumes" would be mounted in the same way (even the root volume).

eg.
Folder "foo" of volume "Mac OS X" would be /Mac OS X/foo.
Folder "foo" of folder "bar" of volume "stuff" would be /Stuff/bar/foo.
If "Mac OS X" is the system disk, / would be /Mac OS X/System/root.

This puts all "system" files into one folder again. You could do a Finder copy to duplicate your system again! Permissions stuff would need to be handled by the Finder of course, but it would be nice.



[ Reply to This | # ]
re: rant
Authored by: recursion on Mar 04, '03 10:41:59PM

actually, that works now too...perhaps it's something I accidentally did, but now my fstab works like that...however, functionality is enhanced if you add a 'mount -v -t hfs -o rw,{options} /dev/disk#s# /mountpoint' in your /etc/rc...also, the previous comments in regards to niload were correct, found that out quickly...as long as you mount the fstab items before autodiskmount arrives, they operate in a traditional UNIX sense....mostly



[ Reply to This | # ]
Create a more dynamic fstab using UUIDs
Authored by: carsten on Mar 04, '03 10:48:14PM

Would this work for volumes with spaces in the name? If so, what changes are needed to these instructions?

Thanks for your research and effort to figure out one of the poorly documented parts of OS X!



[ Reply to This | # ]
Create a more dynamic fstab using UUIDs
Authored by: Hes Nikke on Mar 05, '03 01:55:47AM

it works! after applying the UUID tips here, my mount system actualy works as expected!

see my thread on the other artical to see my issues

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.



[ Reply to This | # ]
Create a more dynamic fstab using UUIDs
Authored by: ged on Mar 05, '03 04:46:52AM

By the way, getmntent isn't a command, it's a C library function. The way you can tell is by which section it's in, which is typically shown in parentheses after the name of the topic, eg., getmntent(3). The sections are traditionally (at least under BSDish systems):

  1. general commands (tools and utilities)
  2. system (kernel) calls
  3. the C libraries
  4. special files and hardware support
  5. file formats
  6. games/demos
  7. miscellaneous information pages
  8. system maintenance and operation commands
  9. kernel internals

Under most man(1) implementations, you can ask for pages only from the section you are looking for:

  $ man 5 fstab
  $ man 1 man

Great hint, BTW.



[ Reply to This | # ]
Create a more dynamic fstab using UUIDs
Authored by: digitalone on Jun 03, '03 04:47:51AM

I have run into problems following the hint the author refers to in the beginning, leading me to a real learning experience with UNIX and drive mounting. This is a newbie question I'm sure, but is this output normal for disktool -l, namely the "unrecognized disk appeared"?

% disktool -l
*** Unrecognized disk appeared on disk1 ***
*** Unrecognized disk appeared on disk1s1 ***
***Disk Appeared ('disk1s2',Mountpoint = '/', fsType = 'hfs', volName = 'MOSX')
***Disk Appeared ('disk1s3',Mountpoint = '/Volumes/DigimacHD', fsType = 'hfs', volName = 'DigimacHD')
*** Unrecognized disk appeared on disk0 ***
*** Unrecognized disk appeared on disk0s1 ***
***Disk Appeared ('disk0s2',Mountpoint = '/Volumes/StorageHD', fsType = 'hfs', volName = 'StorageHD')

Thank you so much in advance for your assistance.

Sean



[ Reply to This | # ]
device vs. devicename - location of uuid file?
Authored by: cilly on Aug 06, '03 02:47:00AM

First, I am confused about the variables you use:

You define a devicename as disk ID, i.e. disk0s10.

Two lines later you use device, should device be different than the devicename?

Second, is there a standard location for the UUID-file?

~/file_to_store_uuid_in can't be the correct location in my opinion.

Which location is used for this and what filename is used?

---
--
info@cilly.com



[ Reply to This | # ]
device vs. devicename - location of uuid file?
Authored by: varelse on Aug 13, '03 05:39:23PM
First: Yes, he used the different variable names for the same device.

Second: that is just a temp file to store the UUID number. You could just run the command without the redirection but it will output to the screen and will put on the same line as your command prompt, for example

root:~# /System/Library/Filesystems/hfs.fs/hfs.util -k disk1s5
76D5956A649AE55Croot:~#

Now you can just cut-and-paste the UUID (16 chars) into fstab but just be sure to NOT get any of the prompt (root:~#)

[ Reply to This | # ]

Panther Experiances with this hint
Authored by: Hes Nikke on Oct 23, '03 10:55:25PM

Panther has some issues with home folders on volumes other then the boot disk.

this is what i have observed with panther over the past couple of days:
When there is NO GUI session logged in, the only volumes mounted are your boot volume (duh) and the volume that hosts your the copy of Mac OS 9 set for classic (huh?)

When you log in, it goes ahead and mounts all your volumes were ever you told them to go in fstab (or the default /Volumes) and you can usually observe this in the finder as it starts with just your 2 volumes in the disks column and then all your other volumes stream in.

Here is the worst part. when the last GUI session logs out, (don't forget fast user switching) all your disks (save classic and boot) unmount again!

At first I though it only mounted the disks after the finder loaded (as i usually wind up with a default dock, default finder window locations and preferences, and an empty desktop) but sometimes I get my custom dock, finder window placement, and desktop icons as it loads the settings from my Users volume.

Here are the 2 and a half workarounds that I have found:

• Set up a 2nd user account (optionally with it's home folder somewhere on your boot partition - good for troubleshooting anyway!) and ALWAYS log into that account 1st. after all your volumes mount, fast user switch to your normal account. This is the method I'm currently using.

• Log in though ssh and manually mount your users partition. that mount will stick though all logouts, but you have to do it every time you boot your computer. the draw back here is that you have to have a second computer. I'm sure you could log into >console and mount it there, but I have not tested this - in fact I haven't even tested if >console is still there, aside from a failed fast user switch.

• Setup some kind of startup item to automate the above during boot. I have no idea what the script in the startup item should be, but i do know how to set up a startup item if someone wants to help me there.

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.



[ Reply to This | # ]
Panther Experiances with this hint
Authored by: Hes Nikke on Nov 11, '03 11:49:52AM
and in combination with this hint, the above becomes a non-issue, and the custom mount point system is now Panther Proven! :D

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.

[ Reply to This | # ]

Create a more dynamic fstab using UUIDs
Authored by: mjtomlin on Nov 01, '03 03:00:56AM

"Be sure that you record the uuids the first time you see them, it becomes annoying to mount and unmount drives more than necessary to get the uuids."

If you use the raw device (rdisk1s10) instead of the associated block device (disk1s10), then it doesn't matter if a volume is mounted or not. You will be able to get the UUID.



[ Reply to This | # ]
Create a more dynamic fstab using UUIDs
Authored by: Hes Nikke on Nov 07, '03 11:15:55AM

if you have more then 2 hard drives, the 2nd, 3rd, 4th etc drives randomly choose raw device ids, making your solution useless (trust me, i've tried, it could be different with panther, but i doubt it.)

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.



[ Reply to This | # ]
Create a more dynamic fstab using UUIDs
Authored by: nickv_111 on Nov 09, '03 04:28:43PM
I tried this hint, and when I tried to "Create a UUID" for my external hard drive, and then send the UUID to a file, the file was blank. I did /System/Library/Filesystems/hfs.fs/hfs.util --help and found no -s or -k options. Is there any way to set a uuid to my hd?

---
~~~~~~~~~~
Nick

[ Reply to This | # ]

Create a more dynamic fstab using UUIDs
Authored by: ptwithy on Nov 30, '03 12:59:29PM

Why does fstab have examples with 32-character UUID's yet hfs.util seems to only reveal a 16-character UUID?



[ Reply to This | # ]
How *I* finally got it to work
Authored by: DeusExMachina on Dec 12, '03 05:07:21AM
Man, I sure had a lot of trouble with this hint!


I don't know what the problem was, but neither of the hfs.util invocations seemed to have any effect for me, and like someone else commented, the documentation seems to be quite out of sync with the actual tool versions we have installed.


For the record, I'm using 10.3.1 (build 7C107) on a 2x2GHz G5. I have partitioned the one SATA drive into 3 partitions, which show up at /dev/(r)disk0s(3|5|7) and the 0s3 one is labeled "Swap" (for now) and intended for use as dedicated swap space.


Anyway, without hfs.util I was SOL for setting or querying UUIDs for these partitions, but as I looked various sources seemed to indicate that the partitions would likely already HAVE UUIDs, so it should just be a matter of finding them out. I think it was some of the documentation for pdisk or one of the other tools that alluded to this fact, which turned out to be true.


But how do you determine these UUIDs? Google pointed me to sysctl, procfs, etc. when referring to UUIDs and partitions on the same page... but none of this stuff applies to Mac OS X. Then I looked in /var/db for some reason, and saw the file /var/db/volinfo.database. Hmm, catting this file reveals 3 lines with 16 character hex strings at their heads, and meaningless other stuff... just the right number of lines for my partitions.


I tried sticking those values into fstab and rebooting... no dice. Anyone know what the heck that file contains?


So then I started thinking about whether the format of the fstab line was correct. After all, the example says


UUID=blah blah /mountpoint hfs 1 2


I assumed that first space was not intended to be replicated... ie


UUID=blahblah /mountpoint hfs 1 2


But is this line space-delimited, or tab-delimited? And why does it have "1 2" where the examples IN the fstab file all have "rw" or "ro" or "noauto"?


Well in the course of experimenting with my by now VERY messed up fstab file, I completely fubarred my system. I couldn't even restart into single-user mode! I couldn't even open the drive tray to boot from a CD! (there's no button I could find on a G5 superdrive, inside or out). I finally got it back by shutting it down completely, and leaving it off for 5 minutes. Then it booted normally, although my fstab still didn't work.


In the course of looking through the system.log that episode had generated, however, I finally solved the problem of finding my UUIDs, and shortly thereafter puzzled out the correct fstab format.


So, to summarize!


Find your UUIDs by looking in system.log with Console and observing the messages generated during a boot. You'll see diskarbitrationd checking all your partitions, and it nicely names them, UUIDs them, device-numbers them, and ices them. The UUIDs are even the long 32char ones like in the fstab samples!


Insert them info your fstab file in space-delimited form like so (assuming FFFF represents your UUID, /mountpoint is an existing folder you want to mount it on, etc.)


UUID=FFFF /mountpoint hfs rw 1 2


NOTE: the hint seems to leave out the "rw" part above, but it IS necessary! Also, the mountpoint must exist as a directory before you try this!


Do all that, and it should work. Anyway, it's 2AM, so I'm going to put any further testing off until tomorrow! :)


DeusExMachina

[ Reply to This | # ]

How *I* finally got it to work
Authored by: BraindeadMac on Jul 07, '04 10:18:30PM

Uh, there's a bit of misinformation in this hint. The UUIDs already exist for drives, use /System/Library/Filesystems/hfs.fs/hfs.util -k to get the UUID for any given device; you don't need to generate a UUID with -s.

To learn more about hfs.util just do type "man hfs.util".....



[ Reply to This | # ]
URGENT........Can you pls help me
Authored by: geeth on Apr 20, '07 12:25:35AM

Whether the UUID specified in /etc/fstab can be cosidered as unique idenifier for a machine....?????
Whether there is any way so that we can make it tamper proof?



[ Reply to This | # ]