Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

0004838

Suspended
Original poster
Oct 1, 2014
193
64
I'm pretty sure I used to do this on Ubuntu a while back, but that was using the "mount bind" command, which I don't think we have on Macs.

I'm trying to arrange it so that a folder on an external USB drive is automatically mounted over a folder on the local drive whenever I mount that USB drive on my Mac.

I looked in FSTAB and the UNION command seems relevant, but FSTAB only seems to operate on filesystems, not folders.

Anyone know?
 
Would a symbolic link meet your requirement?

(I guess you tried that already.)

Can you give more detail on the requirements?

If you like GUIs to things, consider ControlPlane.
 
Would a symbolic link meet your requirement?

(I guess you tried that already.)

Can you give more detail on the requirements?

If you like GUIs to things, consider ControlPlane.

In the middle of my reply to you I suddenly had a brainwave. I'm going to explore it a little and get back to this thread once I know what I'm on to.

Cheers :)
 
Would a symbolic link meet your requirement?

(I guess you tried that already.)

Can you give more detail on the requirements?

If you like GUIs to things, consider ControlPlane.

My brainwave didn't pan out.

The problem with symlinks is that it breaks iTunes if the USB HDD isn't plugged in. A mount --bind solution would get around that. I think separate partition is the only real way round this, but that's not ideal, because I'll have to guess in advance what size to make the partitions. The partitions would be for the iPhone Software Updates and Backups folders, btw, which do not reside within the iTunes folder. So, I'd need at least 3 partitions total, plus a fourth if I want to store other things on the same drive.

It's not ideal. Mount --bind would be the best, but it's LINUX-only. I looked at bindfs but I've read it's unreliable, and there's a performance penalty.

I think I'm all out of ideas. Anything I've missed?
 
File system of a sparse bundle disk image, mounted at ~/Music/iTunes

… iTunes …

That's what I wanted to know, thanks.

… to guess in advance what size to make the partitions. …

Think instead (again) towards a solution that does not involve a fixed size.

I think I'm all out of ideas. Anything I've missed?

Sparse bundle disk image with a nonstandard mount point

Prepare the directory that is to be the mount point.

For example, here's that directory and its (empty) content for user gjp22:

Code:
sh-3.2$ ls -@adel /Users/gjp22/Music/iTunes
drwxr-xr-x  2 root  wheel  2  2 Jan  2014 /Users/gjp22/Music/iTunes
sh-3.2$ ls -@ael /Users/gjp22/Music/iTunes
total 80
drwxr-xr-x   2 root   wheel   2  2 Jan  2014 .
drwx------+ 21 gjp22  wheel  62 18 Jan  2014 ..
 0: group:everyone deny delete
sh-3.2$

Create then detach the image.

If you want an HFS Plus file system, and if you prefer relatively rapid recovery from an ungraceful unmount, then allow journalling.

If you prefer data integrity (within the constraints of HFS Plus) then you might prefer to disable journalling – I can discuss why, but not in this topic.

Consider the nature of the iTunes data in your case. If you wish to experiment with a nonstandard size for the bands of the bundle, then use hdiutil(1), not Disk Utility, to create the image.​

Use the attach verb of hdiutil with option -mountroot and the path to the prepared directory.

Finally, move your iTunes data to the mounted file system.

Take care to not improperly disconnect the device on which the .sparsebundle is stored. If you do so, you may eventually find it necessary to force a restart of the OS (I can discuss why, but not in this topic).

-----

As you're familiar with command line solutions, the brief outline above should be enough to get you started.

Whilst I have not tested that .sparsebundle approach to ~/Music/iTunes I assume that it will be fine. If it's successful then you might like to share something less brief.

(I have used the .sparsebundle approach extensively, and successfully, for other applications.)
 
Hmm, a sparse bundle's an interesting idea. My immediate thoughts are to the possible drawbacks: they're not mountable with FSTAB; won't there be a delay while the bundle is verified and mounted; won't there be a performance hit; aren't they reputed to be fragile, even without human error as a factor?

The first is not such a big deal, I can easily create a script that I run manually after mounting the host drive. The second may be a problem, considering the bundle will be running to at least 600GB, and obviously growing over time. The third is just conjecture, I'll admit. The fourth is based on information from several years back, and I've a suspicion that sparse bundles have been made more robust since.

Would you be able to comment on those last three points, using your experience as a guide?

Thanks for continuing to follow this topic, I appreciate it.
 
The problem with symlinks is that it breaks iTunes if the USB HDD isn't plugged in.

I don't have an installation of Mavericks handy or I would try this before suggesting it, but maybe you can do something like this. It will presume you can get your external disk to mount where you want with a properly created fstab entry. (Yosemite doesn't support /etc/fstab)

1) create an entry for your external USB to mount. Let's say the disk is EXTUSB, so mount it on /Volumes/EXTUSB. You can't let it automount, because if /Volumes/EXTUSB exists, it will mount it on "/Volumes/EXTUSB 1".

2) create a symbolic link. I'll just guess you're doing all of your iTunes Library, so something like "ln -s ~/Music/iTunes /Volumes/EXTUSB/Music/iTunes" assuming that's where you store your library on your external drive.

3) with the external drive unmounted, create the directory structure: "mkdir /Volumes/EXTUSB /Volumes/EXTUSB/Music /Volumes/EXTUSB/Music/iTunes"

When you launch iTunes without the external drive mounted, the symbolic link will point to empty folders under the /Volumes hierarchy; if the external disk is mounted, it will point to the folders on the external drive.

If the automounter still fails to mount the disk in the proper place (that would be the case using fstab with Yosemite), using "mount" from the command line will easily mount external partitions over existing folders without a problem.

Even if this isn't correct for your situation it might give you enough to figure out the exact steps that will work.
 
… a delay while the bundle is verified and mounted …

With normal usage, checksumming before mount should occur only once.

Subsequent mounts should be fast enough:
  1. the time taken for fsck_hfs(8) to quickly check a clean file system; plus
  2. the time taken to mount, which I treat as negligible.

Here, with a mobile hard disk drive limited to USB 2.0, a .sparsebundle that's 215.61 GB on disk with more than thirty-four thousand 8 MB bands:

Code:
/dev/rdisk7s2: fsck_hfs started at Sun Mar 22 03:42:21 2015
/dev/rdisk7s2: /dev/rdisk7s2: ** /dev/rdisk7s2 (NO WRITE)
/dev/rdisk7s2:    Executing fsck_hfs (version hfs-226.1.1).
QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk7s2: fsck_hfs completed at Sun Mar 22 03:42:21 2015

… a performance hit …

Not necessarily.

If performance is not what you'd like, you can backup then experiment with smaller or larger bands within an image.

… reputed to be fragile …

Rewind a few years. When the operating system first used .sparsebundle directories for FileVault 1, things could get messy if (for example) power was forced off whilst the image was attached. But that was more a fragility of the application (FileVault) than of DiskImages.framework or the disk image driver.

I have no idea what versions were current in the early days of FileVault 1 but now, with Mavericks:

Code:
sh-3.2$ hdiutil info -s ; sw_vers
framework       : 371.1
driver          : 10.9v371.1
ProductName:	Mac OS X
ProductVersion:	10.9.5
BuildVersion:	13F1066
sh-3.2$

… I can easily create a script that I run manually after mounting the host drive. …

The run in response to the mount can be automated. I'd like to link to something that should provide inspiration, but some readers respond badly to the presence of links so (with apologies to CliftonHighgrov) I'll refrain.
 
(Yosemite doesn't support /etc/fstab)
Pardon me if I drift off the main topic for a second, but: are you sure? What's your source? This article and this thread suggest fstab works just fine in Yosemite. Perhaps you're confusing it with fstab.hd, as many have done?

@grahamperrin: You've given me plenty to think about. I'll definitely look into implementing this - oh, and I'm sure a web search will pull up the auto mount information you're referring to. Thank you for your help. :)
 
Perhaps you're confusing it with fstab.hd, as many have done?

Possibly, I don't know why I was confused, but I was incorrect. It's possible some feature was removed and I mixed that up with full support.

Now knowing that I tried it, and my suggestion works perfectly, with one caveat: The external cannot be mounted under /Volumes because diskarbitrationd will rename the mount point regardless of what /etc/fstab says. Assuming you are wishing to store a whole iTunes library externally, the steps were something like this:

1) Note name of library and label of external drive; for the example, I'll use the volume label of "EXTUSB" and the place the library in a folder in the root called "iTunes"
2) Create fstab entry:
Code:
LABEL=EXTUSB    /mnt/EXTUSB     hfs     rw
3) create /mnt and mount point (or whatever your favorite temporary mount point is, and use that in the corresponding fstab):
Code:
mkdir /mnt /mnt/EXTUSB
4) move current (empty?) iTunes files there:
Code:
mv ~/Music/iTunes /mnt/EXTUSB/iTunes
5) create symbolic link to new location:
Code:
ln -s /mnt/EXTUSB/iTunes ~/Music/iTunes

Without the external drive mounted, iTunes sees the (empty?) library in /mnt/EXTUSB/iTunes and doesn't complain. Once you plug in the external drive, it mounts the drive on that mount point and uses those files. This is just for an example, I'm not taking into account other directories or caches. Additionally, the external drive still appears as a mounted drive and other files on it can be accessed. If external drives are shown on the desktop or in the Finder sidebar, it will appear there.

I'll correct myself and add a second caveat: On Yosemite, if an icon for the external drive is displayed on the desktop, after ejecting the external drive, the desktop icon doesn't go away immediately. Finder is seeing the folder structure underlying the mount point and the icon is displayed. The level of annoyance to the user is subjective, so I don't know if this is a problem.
 
Possibly, I don't know why I was confused, but I was incorrect. It's possible some feature was removed and I mixed that up with full support.
Thank goodness, I rely on FSTAB.

Now knowing that I tried it, and my suggestion works perfectly[.]
Unfortunately, this is the precise method I can't implement, and for which I'm trying to find a substitute. If I could, I would simply mount the USB HDD to ~/Music/iTunes. But this would mean symlinking iPhone Software Updates and Backups into the iTunes folder, which is messy, and means they'll either be hidden by, or not available to, the mounted drive (depending on where I link them), thereby causing a break under certain circumstances. It would also mean anything else on the drive would have to be stored inside my iTunes folder, which is undesirable. This is why the sparse bundle idea is attractive: it allows me to mount three disk images over the original folders, negating the requirement for fragile symlinks, and without partitioning.

I apologise if I haven't made that clear. I find myself caught between wanting to keep forum posts brief and wanting to provide sufficient information to prevent follow-up posts that do nothing that clarify the original post. Sometimes I swing too much in the one direction. :)

2) Create fstab entry:
Code:
LABEL=EXTUSB    /mnt/EXTUSB     hfs     rw

Just FYI: I'm not sure if you were doing it for my benefit, but LABEL would be better replaced by UUID (assuming your HDD's partition scheme supports them). UUIDs can be gleaned from Disk Utility or by running MOUNT.

:)
 
Unfortunately, this is the precise method I can't implement, and for which I'm trying to find a substitute. If I could, I would simply mount the USB HDD to ~/Music/iTunes. But this would mean symlinking iPhone Software Updates and Backups into the iTunes folder, which is messy, and means they'll either be hidden by, or not available to, the mounted drive (depending on where I link them), thereby causing a break under certain circumstances. It would also mean anything else on the drive would have to be stored inside my iTunes folder, which is undesirable. This is why the sparse bundle idea is attractive: it allows me to mount three disk images over the original folders, negating the requirement for fragile symlinks, and without partitioning.

I apologise if I haven't made that clear. I find myself caught between wanting to keep forum posts brief and wanting to provide sufficient information to prevent follow-up posts that do nothing that clarify the original post. Sometimes I swing too much in the one direction. :)

Yeah, sometimes it's hard to guess what the objective is in the OP without all the info. Personally I would prefer symbolic links all over the place than multiple mounts of disk images. Just because symbolic links are already used all over Mac OSX and other operating systems. It seems pretty simple to have one set of symbolic links that get mounted over by another set. But if it makes management harder for you, I understand.

Just FYI: I'm not sure if you were doing it for my benefit, but LABEL would be better replaced by UUID (assuming your HDD's partition scheme supports them). UUIDs can be gleaned from Disk Utility or by running MOUNT.

Yes after typing all that I didn't want to type a whole UUID! I thought it's clearer for the example and I realized you are fluent with fstab.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.