One of the strengths of the Mac OS has long been its seamless networking with AppleShare or Personal File Sharing servers. Or rather, the seams aren’t particularly apparent when you’re using one of these servers – there’s little you can do on a local hard disk that doesn’t work the same on a remote server volume. But the process of setting up and shutting down connections to AppleShare servers has been troublesome forever. For years, the Chooser was the only way to connect to servers for the first time (though most people then created aliases to commonly used items). In Mac OS 8.5, Apple supplemented the Chooser with the Network Browser, but the old habit of using the Chooser died hard – at least for me – especially since the one thing the Network Browser couldn’t do was help you set AppleShare server volumes to mount at startup.
In Mac OS 9, Apple tried to address the issue of mounting AppleShare server volumes at startup by offering an alternative to the Chooser for setting volumes to mount at startup and by reducing the Mac OS’s reliance on the cryptic AppleShare Prep file for storing passwords to AppleShare servers. Unfortunately, these well-meaning modifications caused some problems for long-time users of AppleShare servers, and those problems were exacerbated by Apple’s minimal documentation of the changes.
Servers Folder — Although the Network Browser allowed users to avoid the Chooser somewhat, the Chooser remained necessary in Mac OS 8.5 and 8.6 if you wanted to set servers to mount at startup (or to stop them from doing so). That information has long been stored in the AppleShare Prep file in the Preference folder; experienced users knew that trashing that file was a fast solution to quirky server mounting problems.
Apple decided to reduce our reliance on the Chooser and simultaneously expose the information about server volumes set to mount at startup by creating a special Servers folder inside the Mac OS 9 System Folder. Aliases to server volumes in that folder would be mounted at startup, and Apple changed the Chooser so it would create those aliases instead of using the AppleShare Prep file. You can also drag aliases to server volumes onto the System Folder to have them automatically placed in the Servers folder; dragging a server volume from the Network Browser has the same effect.
The main problem with this entire situation is that Apple has barely documented it at all. There’s no mention of it in the Mac Help accessible from the Finder’s Help menu, and it took several searches in Apple’s Tech Info Library before I found any information.
I encountered this mystery when I changed my internal file server setup recently, swapping a Power Macintosh 8500 with a pair of 2 GB external hard disks for a 6400 with a single 60 GB internal hard disk to hold our MP3 collection. We use the kitchen Mac, a PowerBook G3, to play those MP3s, so it needs access to the server at all times. I’d originally set it to mount the two 2 GB hard disks from the server at startup, but since the PowerBook can go weeks or months between restarts, I’d forgotten that fact when I made the server change. And even then, I probably would have put up with the annoying dialog boxes asking for my password at startup except that they crashed the Classic environment in Mac OS X Public Beta. So I decided to eliminate them.
It took me quite some time and troubleshooting effort before I solved the problem. I tried deleting the AppleShare Prep file (the historical solution), booting with minimal extension sets, rebuilding the desktop, zapping the PRAM, deleting the Keychain, replacing the entire Preferences folder temporarily, and even reinstalling the Mac OS. Nothing worked (though in retrospect a clean installation of the Mac OS would have), so finally I searched for all aliases and started examining them manually to see if any of them could be implicated. That was when I found the Servers folder containing the aliases to the two nonexistent hard disks; trashing them solved the problem instantly. From there, it wasn’t too hard to learn about it in the Tech Info Library, though searching on "connect, server, startup" found only one useful document, the ReadMe for the AppleShare Client 3.8.6 (which provided pretty good information). It wasn’t until I searched on "Servers folder" that I found the article explaining what the Servers folder was, though not what it replaced.
One way or another, though, Apple did provide the answer, and I have to shoulder some of the blame for spending time working through tedious troubleshooting procedures when the answer existed in the Tech Info Library.
Quiz Results — Clearly I wasn’t alone in my ignorance of this change, since just over 40 percent of the respondents in last week’s quiz chose the right answer. Roughly another 30 percent knew the old method of deleting the AppleShare Prep file and more than 20 percent thought the Control key had something to do with it (it doesn’t – holding the Control key down at startup either drops you into the MacsBug debugger immediately or lets you choose a Location Manager module, as we learned in "Modifying the Macintosh Startup Sequence" in TidBITS-529).
Keychain Kops — More problematic in this arena is Apple’s new (in Mac OS 9) reliance on the Keychain for storing passwords to servers set to mount at startup. It’s not an unreasonable approach; the Keychain’s security is undoubtedly better than storing passwords in the AppleShare Prep file, which is where the Chooser previously stashed your name and password for such servers.
Unfortunately, relying on the Keychain for password storage means that you can no longer mount server volumes in an entirely unattended fashion. You may not have to enter the password for the server, but you must still enter the Keychain’s password at some point. Although it’s possible to leave that password blank (a bad idea for security reasons), you would still have to respond to the dialog box that asks for your password. It’s hard to quibble with Apple trying to improve security in this way, but many people have internal AppleShare servers that they use constantly and that aren’t accessible to the outside world in any way. In those cases, the new reliance on the Keychain actually removes functionality – totally unattended server mounting – from the Mac OS.
Apple has once again been quiet about how to address this problem in official documentation. Although I was again able to find the solution in the Tech Info Library, it was nominally for a different problem. If you really want to have one or more AppleShare server volumes mounted at startup without requiring any attention from you, you can create a single-line AppleScript script in Script Editor, save it as an application (turn off Stay Open and turn on Never Show Startup Screen in the Save dialog box), and place it in your Startup Items folder. The one line in the script should be like the one which follows, with the quoted items replaced (leave the quotes intact) with the appropriate volume and server. Unless you’re accessing a server using guest access, you’ll also have to include your user name and password, of course, and you should make sure exposing this password won’t compromise other passwords.
mount volume "volumename or URL" on server "server" as user name "user" with password "password"
One other warning – if you know your server is offline for some reason, make sure to move the script out of your Startup Items folder; it doesn’t handle errors gracefully.
Moral of the Stories — I’m peeved at myself that it took me as long as it did to solve the problem with the phantom server volumes trying to mount at startup. In the end, though, I don’t really mind since I learned something and, by writing about it, I’ll hopefully help some other people make better use of their Macs.
That aside, two things worry me. If a less experienced Macintosh user had run into this problem, they probably would have suffered with it for quite some time, since finding the answer in Apple’s technical documentation is well beyond an inexperienced user. Documentation is seen today as something that’s unnecessary because programs are so wonderfully easy to use that no one ever has any troubles, or at least very few (apologies to Dr. Seuss). I hope the sarcasm in that sentence doesn’t make a puddle on the floor – a few good examples notwithstanding, the overall state of documentation in the industry right now is pathetic.
Second, as this situation showed, the vast amount of experience I have with Macs and AppleShare networks was totally useless because Apple changed one small thing. I’ve played with Mac OS X Public Beta, and although I’m sure changes will be made, I continue to worry that many existing Macintosh experts will find themselves at sea in Mac OS X’s completely new environment. Even if it’s easy to use, that doesn’t mean it will be easy to troubleshoot. We can always hope it won’t need much troubleshooting, but assuming that of an initial release seems optimistic at best.
The solution? Back up a paragraph. It’s documentation – and I hope Apple plans to offer more than paltry online help. Documentation should do more than document. It should explain, teach, provide background, and perhaps even inspire the reader to explore. Technical manuals aren’t novels, but a great manual is no less of a window into another world, and the world revealed by a manual is real.