Japanese Version UK mirror

AppleVolumes - configures exported volumes

Last updated: April 3, 1997
There are two config files looked for by etc/afpd. (AppleVolumes.system and AppleVolumes.default) They both have the same format. The only differience is that users coming in as guest will only get the volumes listed in the AppleVolumes.default file. (as well as only having guest privelage) Usually I use AppleVolumes.system to export the directories that everyone should be able to see such as /usr2/data and AppleVolumes.default exports private stuff such as ~/, the home directory of the user. There are examples of each of these files in your netatalk source directory under etc/afpd/. They are etc.AppleVolumes.system and etc.AppleVolumes.default. You should copy these two files into your DESTDIR/etc directory (usually /usr/local/atalk/etc) and get rid of the etc. in front of the names. One of my AppleVolumes.system files is below:

/usr2/data Thak
/usr4/extra_space "Extra Space"
.txt TEXT MSWD
.TXT TEXT MSWD
.html TEXT TTXT
.HTML TEXT TTXT
.gif GIFf 8BIM
.jpg JPEG 8BIM
.jpeg JPEG 8BIM

In this example, the directory /usr2/data should look like a mountable Appleshare volume on the network with the name Thak. (Thak is one of the Appleshare volumes available on the fileserver Outpost in the Far Side zone.) The volume "Extra Space" is a second exported volume from the same machine, but linked somewhere else in the directory structure. (in my case, another huge hard drive at /usr2/extra_space) I'm not aware of any limit on the number of volumes which can be exported.

When a user logs into the Appleshare fileserver, he logs in with a name and password pair from the Unix server. To deal with this, I created several user accounts on the Unix side for the Macs which will be logging into my Unix box. I gave appropriate read/write file permissions to these users so they could read and write in the exported directory. (/usr/data) Revoking write permission, by the way, is a great way to protect things, such as programs, from getting over-written.

The files not created by a Macintosh follow the type/creator statements below the volume statement. Macintosh computers remember what program created it's files as well as what type of file each is independant of the file name. (This is to say a text file doesn't have to end in .txt for the Mac to know it's a text file.) A Macintosh file is stored with a resource fork as well as a data fork. In the resource fork, a Mac saves the type and creator of the file's contents. If a file is created on the Unix side, there isn't a resource fork. So to fake this, afpd reads in extension - to - Type / Creator mappings from the AppleVolumes file.

In the example above (.txt TEXT MSWD) I map all Unix created files ending in a .txt to have a type of TEXT (obviously text) and a creator of MSWD, or Microsoft Word. If I create a file in Unix called test.txt and saved it in the /usr/data directory, then if I double click the icon for that file on a Mac with that Appleshare volume mounted, the Mac would launch Microsoft Word (granted it's installed) with the text file. The other creator mappings, TTXT and 8BIM corrospond to TeachText and Adobe Photoshop respectivly.

One way of figuring out type/creator mappings is to use the program ResEdit. Launch ResEdit, and say cancel to the file requestor that comes up. Then go File then Get File/Folder Info.... Another requestor box will come up. Open a the file you wish to find the type/creator tags for and they will be in the Info box that pops up. I think ResEdit is widely available. I've used it as long as I can remember...

Another (easier) way of figuring out type/creator mappings is to use the Snitch extension which gives the finder the ability to display (and edit) type/creator entries for a file in the Get Info dialog box.

Probably the easiest way of all to accomplish type/creator mappings is just to download the big type/creator list that Steve Johnson is mantaining.

Note: The hfs filesystem module referred to at the end of the main page has support for automagic file type/creator mappings. The filesystem reads the type/creator fields from the files on the disc and passes them to afpd via the .AppleDouble file system. (same one netatalk uses to write mac files on Unix volumes)