Troubleshooting Automounts

One of the coolest, but most confusing, features of an OS X Server is the ability to set up automounting sharepoints.

This article discusses some techniques for figuring out where things went wrong.

How to set them up.

An automount consists of two things. The first is a valid sharepoint. So go into Workgroup Manager and make sure that you have a working sharepoint.

Next you need to create a mount record for the sharepoint. This record lives in your chosen network directory service, LDAP for 10.3 or NetInfo for 10.2, and alerts all of the client machines that you have an automounting sharepoint.

You enable the mount record in WGM by selecting the sharepoint and then clicking on the Network Mount button to the right. Use the "Where" pull down to select the directory service that you want to create the mount record in. Usually this is gong to be "LDAPv3/127.0.0.1 if you are doing this on the server. Then click on the lock and authenticate as an admin user in that directory domain. Finally you can enable the mount record by selecting the "Create a mount record for this sharepoint" check box.

For the protocol pick "AFP." For the most part this is an easier and simpler method than NFS. Not that NFS doesn't have its uses, just that you'll get further faster with AFP.

You have a couple of options for what you want to do with the automount. Problem is that prior to 10.3.3 only "User Home Directories" and "Custom mount path" work. So ignore the others if you haven't upgraded. Essentially the difference between these two is that the home directories option is dynamic and the custom path is static.

Dynamic automounts are not actually mounted until the user navigates into the folder. Also dynamic automounts mount in /Network/Servers.

Static mounts are mounted at boot time and stay connected until the machine is shut down. Unlike dynamic mounts you can customize where the static mount actually shows up in /Network.

Hit "Save" and you have an automount. The server does not need to be restarted, however, before the client machines will be able to use a static automount they'll need to be rebooted. Dynamic automounts in recent version of 10.3 will be found as needed, so no need to reboot.

Troubleshooting

Since there are a number of different steps to the automounting process there are a number of different places where they can get funky. All the pieces have to be in place for the whole process to work.

1. Check the record in the directory service.

For the mount to work, the mount record in the directory service has to be accessible to the client machine. Even more so it needs to be accessible by the clients at boot time.

The record doesn't have to live on the same server as the user record does. It just has to be on a server in the client's authentication path, as set in Directory Access.

If the record doesn't exist, you'll need to recreate it in Workgroup Manger. Or if you are using 10.3 you can enable the Inspector function, in WGM preference's, and edit the record by hand.

The mount record will have url associated with it, Make sure that this url is actually valid. Cut and paste the url into a "connect to" dialog and prove that it's actually valid. If this url won't work the automount probably won't work. It's important to test the url from the client, not the server. WGM likes to list the url as a DNS name and not a raw IP address. If DNS is bad, or the client isn't using the same as the server the mount will fail.

2. Check and make sure that the client is getting the mount record.

On the client machine use lookupd in debug mode to test this.

lookupd -d

Now query for all mount records with:

allMounts

This should return all mountpoints that are being read in by the client machine. If you don't see the automount that you are looking for you'll need to check Directory Access on the client machine and make sure that it's connecting to the server in the correct way.

Once you've double-checked Directory Access you'll have to troubleshoot the network as normal. Make sure the client can ping the server that kind of thing.

3. Run the automount process by hand.

This is usually the most elucidating step in troubleshooting these problems. If you know the client can see the mount point and that the mount point contains a valid URL try this step next.

On the client machine force automount to run in debug mode using the automounts from directory services. This process is normally handled by the NFS startup item at boot. However doing it by hand will allow for a lot more degugging info.

sudo automount -m /automount/Servers -mnt /private/var/automount/Network/Servers -d

Common problems that you'll see here is that the mountpoint on the local machine already has a folder or file in it. Automount will not overmount an existing file, so you'll need to remove that file first. It's quite possible that you didn't put the file there in the first place, however. When automounts are incorrectly formatted or otherwise messed up it's very possible that automount will attempt to mount the sharepoint and fail. However in the process it will leave a folder on the local machine where the mount point was going to go. This needs to be cleaned up.

4. Turn on guest access.

While home folder and group folder automounts don't need guest access enabled, all other mounts do. So, if you are trying to share out an application or a fonts share point to your client machines you'll need to make sure that guests can access that sharepoint. No guest, no mount.

The one way around this is to use kerberos to authenticate your users. Configure your clients and servers as normal to use kerberos and the clients don't have much choice but to use kerberos authentication for the shares. 5. Group folders.

Group folders are a different beast than any other type of sharepoint on OSX. To enable a group sharepoint on 10.3 you'll need to enable an automounting directory. This is NOT the actual group folder, but a folder that will hold all group folders. Many people think they want a "group" folder, but after setting one up and reading about how it works, they end up with just a normal automounting sharepoint. That's not to say that group folders are bad, just that they are a very specific beast created with the education market in mind.

You need to have done at least four things before a group folder will work on 10.3.

First of all you need to create set a sharepoint to automount. Do this in Workgroup Manager by authenticating to your LDAP domain and then checking the mount record box. There is not a radio button for Group folders at the bottom of this window. However, feel free to use the button for user home directories as that will work just as well. Remember this isn't the actual folder that you want to make into a Group folder. Instead this is the folder that will contain all group folders that you will set up.

Second, go into the group record that you want to assign the Group folder too. Again this is in Workgroup Manager. Here you have a tab to show you the folders associated with the group. If you have done the mount record right, you should see the sharepoint you set up in step one here. Select this sharepoint.

Third, set a user to be the owner of the Group folder. You have to do this. Failure to do so will prevent the Group folder from working. Here is where a Group folder is different than any other sharepoint on the system. The owner that you specify will become the owner for any file or folder that is created or placed inside this share. File permissions still work the same as other shares for the group and everyone else. However, let me repeat this, the owner that you specify here will become the owner of all files and folders in this share.

Fourth, now you can run the command that will generate the folder itself. Why they didn't put this into the GUI I have no idea. So scurry on down to the CLI on the server and run this command.

sudo creategroupfolder

If you hang around long enough, like overnight, the system is supposed to autocreate the folder for you, but why wait.

6. 10.3.5

Prior to 10.3.5 you were limited to a 50 character url for your automount url, including the path to the actual folder you were automounting. See this kbase article 107695 for more information.

In 10.3.5 Apple wanted to give you a bit more room to move in, so instead of the local mount point being /private/var/automount/Network/Servers, it's now /automount/Network/Servers. A savings of 12 characters. You now have 62 characters to work your magic.

However, it has been reported that this breaks some things. Your mileage may vary, but if things go funky you should be able to put things back to where they were on the clients by symlinking the old to the new.

sudo ln -s /private/automount/Network /automount/Network.