Automounting Shares in Mac OS X

[Nezil]

I started writing this post as a reply to a question about iSCSI, but it occurred to me that it might be useful to a more general audience. Moderators, feel free to move this if I've posted in the wrong section.

 

An easy way to make your unRAID shares appear local on a Mac, and automatically mount - Use the Automount system.

 

I'm relatively new to unRAID myself, and have been playing with this approach for several reasons. I'm primarily a Mac user, and don't have a lot of interest in using Windows; and the AFP support in the latest 5.0b versions is a pleasant improvement.

 

For automount to work, there are just a few files to edit, all located in /etc on your Mac.

 

The file /etc/auto_master lists all of the drives mounted in the automount system for your computer. By default it should look like this:

 

+auto_master            # Use directory service
/net                    -hosts          -nobrowse,hidefromfinder,nosuid
/home                   auto_home       -nobrowse,hidefromfinder
/Network/Servers        -fstab
/-                      -static

 

There are actually two approaches to having shared resources automatically mount in the finder:

 

The first is to use the deprecated, and no longer officially supported (though it does work well for Snow Leopard, so I've read) fstab system that will likely be familiar to Linux users. Shares here will always appear in /Network/Servers on your Mac (regardless of where you defined the mount point in fstab), so won't actually fulfil your intention of having them appear as local disks. I'll not be discussing this here, as I don't have a lot of experience with this.

 

The second option is to use standard automount system to define mount points and their shares. You could define these in the auto_master file, but the typical, and cleaner way to do it, is to point auto_master to a new file where you'll add your definitions. My auto_master file looks like this.

 

+auto_master            # Use directory service
/net                    -hosts          -nobrowse,hidefromfinder,nosuid
/home                   auto_home       -nobrowse,hidefromfinder
/Network/Servers        -fstab
/-                      -static
/-                      unraid

 

I then have another file, /etc/unraid with my definitions:

 

/unRAID/TV     -fstype=afp   afp://[user]:[password]@unraid.nezil.com/TV/
/unRAID/Movies -fstype=afp   afp://[user]:[password]@unraid.nezil.com/Movies/

 

In my case, I first created a folder in the root of my disk called unRAID, the automount system then places the TV and Movie folders in there. If for any reason the unRAID server is offline or unavailable, there will be nothing in the folders. When it comes back online, the folders will be populated automatically.

 

Note: I'm running a DNS server in my house, so I'm able to reference the unRAID box using a fully qualified domain name. If you're not running DNS (most likely), you'll need to either use the server's IP address or Bonjour name ending in .local

 

There are some restrictions to this system however...

 

• I have not been able to reliably create mount points in the /Volumes location. (It is possible, as long as there are no other shares with the same name that you would mount in the normal way - Something quite likely if you browse to your server using Bonjour)
  
• Mount points must be on a path with no spaces, escaping a space with a backslash doesn't seem to work
  
• You can only mount the root of an AFP share, not a sub-folder (actually an AFP restriction - discussed more below)
  
• Shares mounted in this way do not appear in the Finder Sidebar, but it's possible to add the folder to the 'Places' part of the sidebar
  

 

It is possible to mount SMB shares in this way as well, the syntax is slightly different though:

 

[mount point] -fstype=smbfs    ://[username]:[password]@[server]/[share]/[folder]

 

SMB shares overcome issue number 3 above, as it's possible to mount sub folders of a share in this way. There is a sacrifice in performance using SMB instead of AFP however.

 

Final Point about AFP Shares

 

One final point I should mention, goes back to the restrictions of AFP. This is nothing new, is mentioned in other forums posts, and is mentioned in the wiki (though it's tough to find) but it confused me a bit in the past.

 

When a Mac connects to an AFP share, it create lots of additional little files as it goes. These files are hidden, so you'd probably never know they existed. The downside to this (besides the obvious clutter), is that problems can occur if you are able to browse to the same location in more than one way.

 

The most obvious example of this is if you were able to browse to individual disks in your array, as well as user shares. Doing this will create conflicting hidden files as you browse, because the user shares exist both themselves, and as folders on each disk, and whilst (in my experience) it doesn't really stop things from working completely, it slows browsing down considerably; possibly because these hidden files are being re-written each time you browse.

 

AFP shares from a typical Mac system will never have this problem, because it's impossible to arrive at the same place in two ways. AFP shares can only be mounted as the root of the share, rather than a subfolder, and any symlinks exported in a share do not work. These restrictions can be frustrating (even to a Mac user like myself), but I'm happy to live with them for the performance benefits they bring.

[defected07]

So maybe an easy fix for the AFP shares and the hidden files generated, is to not export disk shares via AFP? Or only export disk shares via AFP? Obviously, I'd prefer the former, as user shares, split levels, and data allocation algorithms are some of the major points of unRAID.  Would exporting only User Shares via AFP solver the potential performance issues you described?

 

Thanks for this write up, by the way. It looks very informative. speeding_ant constructed a shell script, along with a launchd .plist for Wake On Lan, mounting, and unmounting user shares via AFP or SMB.

[dgaschk]

Eventually it will not be possible to export a disk as a disk share and as part of a user share. This restriction has not been implemented yet.

[jmangelini]

An utility to wake on lan then automount at:

http://tinypay.me/jma

 

 

Moderator: user shows no indications of being a spammer (apart from this!), but popped in here for a few minutes, posted twice about his utility, and has never come back.  Link does not work.

 

[Joe L.]

Eventually it will not be possible to export a disk as a disk share and as part of a user share. This restriction has not been implemented yet.

I would argue that is a un-needed restriction and one likely to be opposed by many. 

 

There is a VERY GOOD reason to have both sets of shares.  (You can hand allocate directories and files when writing them to the array using disk shares, but still see the directories as a union of the physical drives under user-shares when reading by media players.)

[dgaschk]

Eventually it will not be possible to export a disk as a disk share and as part of a user share. This restriction has not been implemented yet.

I would argue that is a un-needed restriction and one likely to be opposed by many. 

 

There is a VERY GOOD reason to have both sets of shares.  (You can hand allocate directories and files when writing them to the array using disk shares, but still see the directories as a union of the physical drives under user-shares when reading by media players.)

 

This would only be applied to AFP shares due to AFP limitations under unRAID's particular system. I believe that AFP will not work properly when multiple shares partially overlap.

[auralarch]

I know this is an old thread, but I just wanted to add a little info for anyone like myself who may find this in their search for answers...

 

 

There are some restrictions to this system however...

• Mount points must be on a path with no spaces, escaping a space with a backslash doesn't seem to work
  

 

 

It IS actually possible to mount a path with spaces (the method tried by the OP just wasn't quite right).  Spaces must be replaced with

 '\040' (instead of simply escaped w/backslash).

So "My Data Drive" mounted in "Volumes" would be '/Volumes/My\040Data\040Drive'



[This information is available in the fstab manual.  To access: type 'man fstab' on the command line (in the terminal).]

[UKenGB]

I know this is an old thread, but I just wanted to add a little info for anyone like myself who may find this in their search for answers...

 

 

There are some restrictions to this system however...

• Mount points must be on a path with no spaces, escaping a space with a backslash doesn't seem to work
  

 

 

It IS actually possible to mount a path with spaces (the method tried by the OP just wasn't quite right).  Spaces must be replaced with

 '\040' (instead of simply escaped w/backslash).

So "My Data Drive" mounted in "Volumes" would be '/Volumes/My\040Data\040Drive'



[This information is available in the fstab manual.  To access: type 'man fstab' on the command line (in the terminal).]

 

I love it (NOT) when I see smart replies like this. Can I ask auralarch if he ever actually tried his solution. I'm guessing not since if he had he would know that it doesn't work. For several iterations of OSX, automount has NOT done what the man page clearly states it should. There is a section stating that \ can be used to escape spaces or other special characters, or you can use "..." around it all. But the fact is NEITHER of this works at all as all characters are simply treated the same so in the example given, it would be looking for or trying to use /Volumes/My\040Data\040Drive which of course does not exist. The \ is just used as a normal character and doesn't escape anything.

 

You can use \ to escape spaces when exporting shares, the problem appears to be limited to automount which somehow has lost the code to use \ and " to escape spaces etc. and can only be considered a bug and after all these years, one that needs fixing. I would think it's not a complicated fix either.

 

Since this particular bug is a MAJOR problem for me currently as I do need to share and mount with spaces in the names, I would be DELIGHTED to be proved wrong and someone explain how you really can enable the use of spaces.