This article explains how to connect your Mac OS 9 computers to an Network Attached Storage (NAS) device using NFS, linux and netatalk. Why would someone want to do this?
Though this article specificly deals with the Iomega NAS 100d line, I am confident that it will work with other NAS devices that don't support OS 9 out of the box as well.
I manage a small network of about 10 Windows PCs, 5 Mac OS X machines, 6 Mac OS 9 machines, 2 linux servers and a few different printers and print servers. In order to allow users to access files that are related to client jobs (this is an advertising agency, BTW), we need to have all these machines connect to a file server. With growth in our client base and size of projects, our 60GB Mac server became too small. Therefore, we needed a cheap way to expand our storage.
After some research, I found that our best option was to get the ~US$200 Iomega NAS 100d 160GB units. (We got 2 of them for doing mirror backups and some other operations that I will not go into here. The information that I read about these units all said something similar to "Mac compatible," never specifying that the unit only supported SMB and NFS. Needless to say, when I girst tried to connect, I was not too pleased. However, since I had netatalk already running on the network from a linux server, I decided that would be the best bet.
Since I already had a debian server running on the network with the netatalk service pumping along, I figured I'd simply attach the NAS to the linux server and share it out over AppleTalk from there.
Seemed simple enough; however, when I started running into problems, I could not find anything on the net that would help me get things working correctly. In this article, I will outline what I had to do to overcome the problems I had in hopes that this will be of some use for other people attempting something similar.
Obviously, this had to be the first step in the process after the NAS was running on the network correctly. The very first thing I had to do was set up an NFS client on the server. I loaded up the nsf-common package through aptitude on the Debian (Sarge) server.
Once that was all installed, I just needed to make sure I could attach to the NAS. I went into the NAS configuration, created a new share called "mirrr" and restarted. When that was back online, I needed to be sure that the share was available, so I checked it:
# showmount -e 192.168.1.4 Export list for 192.168.1.4: Share * /home/mirror (everyone)
All looked good, so I did a test mount using the following command to be sure access was granted. (I had created the /mnt/mirror directory on the linux server previously.)
mount -t nfs 192.168.1.4:/home/mirror /mnt/mirror
Once I was able to connect, I decided that I would need to have the share be mounted at boot time. To accommodate for this, I went in and added a line to my /etc/fstab file:
192.168.1.4:/home/mirror /mnt/mirror nfs rw,nfsvers=3,udp,sync,hard,intr,async,nodev,nosuid,nolock 0 0
You can find more about the different nfs options all over the net, so I won't list what they all do here. These are the final options that I went with (still testing actually) which was derived from many unsuccessful attempts.
Once the linux server has access to the NAS shares, it is time to export them to the AppleTalk network using the netatalk service. I wanted to allow guest login for couple share I already had, but I also wanted to force logins for the other shares.
To do this, I had to first edit my /etc/netatalk/afpd.conf to define the server that would appear on the AppleTalk network:
"File Server" -uamlist uams_dbx.so,uams_clrtxt.so,uams_guest.so -savepassword -setpassword -icon -ipaddr 192.168.1.3 -nouservol -advertise_ssh
NOTE: The above must be all on one line to work correctly! Mac OS X clients can use ssh because of the -advertise_ssh option if it is available to them. Another thing to note about this set up is that when OS X clients attempt to connect without ssh, you will be warned that the passwords are being sent clear text. For more information about these options, check out the netatalk sourceforce website.
Once the service was set up to run, announce and be found through chooser, it was time to share some volumes. To do this, you need to define them in the /etc/netatalk/AppleVolumes.default file.
The first share that I wanted available was a personal directory for each user. I also wanted to enforce the rules for file naming as you find in a Windows environment. Anyone that belongs to the system group call "users" should be able to use this share:
~/ "Personal Directory" options:mswindows allow:@users
Next, I did have a public share for all Mac users to get to. This is the place that most files uploaded from our clients end up at (Some files are uploaded or sent in other ways to protect privacy even from our employees that don't need to see them.):
/var/uploads "Client Uploads" options:mswindows
Now, I needed to add the NAS to the list. Because this is a network share of a network share, I was worried that files would get corrupted, especially the index files that AppleTalk networks use. Therefore, I used the dbpath option to store these index files on a local disk. Since primarily Macs would be accessing this volume, I didn't force any file name restrictions. You will want to replace somegroup with a group on your system that you want to allow access for. Remember, Debian by default puts each user in its own group, so you may want to define a special group for this purpose.
/mnt/ClientFiles "Client Files" allow:@somegroup dbpath:/var/local/ClientFiles
I also wanted to be sure that I had the other NAS mirror counterpart shared. The only differences between the two units are the IP address, the mount point on the linux server, and the netatalk volume name. Also note that this mirror share is exported as read only.
/mnt/mClientFiles "Client Files Mirror" options:ro allow:@somegroup dbpath:/var/local/mClientFiles
File permissions can be a pain sometimes for a community repository like I have set up, so you will want to be aware of that. One solution to this could be to set up a cron job to chmod and chown the volume contents. Netatalk doesn't support a "force user" option like Samba, so this is the quick fix that I have used in the past. Suggestions welcome!
Every problem that I encountered ended up to be the result of how I mounted the NAS via NFS. It took me about 3 days of trying different netatalk configurations before I all but gave up.
I was able to do everything the way I wanted it to work with all the volumes but the NAS one (the second NAS was added afterward). After asking a few friends, and getting no results from USENET groups, I was growing quite frustrated.
I finally decided that netatalk was set up exactly how it should be, and turned my attention to the NAS unit. Because I was having problems connecting OS X directly to the NAS, I thought it might have been the unit itself. I did manage to find some artricles talking about the OS X 10.4 problems, so I tried the connection on an OS X 10.2 machine, and it worked fine.
This made me realize that it could be how the NAS was mounted on the linux server, and that is exactly the problem. Because I did not have the nolock option set, netatalk was not able to write files to the NAS, giving me all kinds of odd errors from the client machines. Just by luck, I tried adding the nolock option, and it worked perfectly. The only reason I tried that option was because I could not find any useful documentation of the exact effects of it.
Because I specified nolock, I was worried that some of our files could be saved over while another user had it open. Since about 98% of the files that this could happen to were Quark XPress files, I copied one to the NAS and opened it on one of the Macs. I then attempted to open it on another machine (even using different OS and Quark versions to be sure), and I wasn't allowed to open it. Because that happened, I was satisfied with the result.
I have yet to copy over the 60GB of data from the Mac OS 9 server to the NAS, but if I have any problems with that, I will need to come back and edit this article. If that happens, I will add an update section at the end here so that people can find what things I needed to change quickly.
All code and scripts available for download on http://koivi.com are written by Justin Koivisto, ZCE and fall under the GNU Lesser General Public License (LGPL) Version 2.1 (unless noted otherwise). The full license agreement can be found within the LICENSE file within each distribution package.
© 2004 - Justin Koivisto, ZCE
Valid XHTML 1.0