Linux NFS-HOWTO | ||
---|---|---|
Prev |
Following is a list of known issues for using Linux together with major operating systems.
The format for the /etc/exports file for our example in Section 3 is:
/usr slave1.foo.com:slave2.foo.com,access=slave1.foo.com:slave2.foo.com /home slave1.foo.com:slave2.foo.com,rw=slave1.foo.com:slave2.foo.com |
AIX uses the file /etc/filesystems instead of /etc/fstab. A sample entry, based on the example in Section 4, looks like this:
/mnt/home: dev = "/home" vfs = nfs nodename = master.foo.com mount = true options = bg,hard,intr,rsize=1024,wsize=1024,vers=2,proto=udp account = false |
Version 4.3.2 of AIX, and possibly earlier versions as well, requires that file systems be exported with the insecure option, which causes NFS to listen to requests from insecure ports (i.e., ports above 1024, to which non-root users can bind). Older versions of AIX do not seem to require this.
AIX clients will default to mounting version 3 NFS over TCP. If your Linux server does not support this, then you may need to specify vers=2 and/or proto=udp in your mount options.
Using netmasks in /etc/exports seems to sometimes cause clients to lose mounts when another client is reset. This can be fixed by listing out hosts explicitly.
Apparently automount in AIX 4.3.2 is rather broken.
In general, Tru64 Unix servers work quite smoothly with Linux clients. The format for the /etc/exports file for our example in Section 3 is:
/usr slave1.foo.com:slave2.foo.com \ -access=slave1.foo.com:slave2.foo.com \ /home slave1.foo.com:slave2.foo.com \ -rw=slave1.foo.com:slave2.foo.com \ -root=slave1.foo.com:slave2.foo.com |
(The root option is listed in the last entry for informational purposes only; its use is not recommended unless necessary.)
Tru64 checks the /etc/exports file every time there is a mount request so you do not need to run the exportfs command; in fact on many versions of Tru64 Unix the command does not exist.
A sample /etc/exports entry on HP-UX looks like this:
/usr -ro,access=slave1.foo.com:slave2.foo.com /home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com |
A sample /etc/exports entry on IRIX looks like this:
/usr -ro,access=slave1.foo.com:slave2.foo.com /home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com |
http://www.fys.uio.no/~trondmy/src/2.4.17/linux-2.4.17-seekdir.dif
IRIX servers do not always use the same fsid attribute field across reboots, which results in inode number mismatch errors on a Linux client if the mounted IRIX server reboots. A patch is available from:
http://www.geocrawler.com/lists/3/SourceForge/789/0/7777454/
Linux kernels v2.4.9 and above have problems reading large directories (hundreds of files) from exported IRIX XFS file systems that were made with naming version=1. The reason for the problem can be found at:
http://www.geocrawler.com/archives/3/789/2001/9/100/6531172/
The naming version can be found by using (on the IRIX server):
xfs_growfs -n mount_point |
The workaround is to export these file systems using the -32bitclients option in the /etc/exports file. The fix is to convert the file system to 'naming version=2'. Unfortunately the only way to do this is by a backup/mkfs/restore.
mkfs_xfs on IRIX 6.5.14 (and above) creates naming version=2 XFS file systems by default. On IRIX 6.5.5 to 6.5.13, use:
mkfs_xfs -n version=2 device |
Versions of IRIX prior to 6.5.5 do not support naming version=2 XFS file systems.
# mount linux:/disk1 /mnt # cd /mnt/xyz/abc # pwd /xyz/abc |
Solaris has a slightly different format on the server end from other operating systems. Instead of /etc/exports, the configuration file is /etc/dfs/dfstab. Entries are of the form of a share command, where the syntax for the example in Section 3 would look like
share -o rw=slave1,slave2 -d "Master Usr" /usr |
Solaris servers are especially sensitive to packet size. If you are using a Linux client with a Solaris server, be sure to set rsize and wsize to 32768 at mount time.
Finally, there is an issue with root squashing on Solaris: root gets mapped to the user noone, which is not the same as the user nobody. If you are having trouble with file permissions as root on the client machine, be sure to check that the mapping works as you expect.
Solaris clients will regularly produce the following message:
svc: unknown program 100227 (me 100003) |
SunOS only has NFS Version 2 over UDP.
On the server end, SunOS uses the most traditional format for its /etc/exports file. The example in Section 3 would look like:
/usr -access=slave1.foo.com,slave2.foo.com /home -rw=slave1.foo.com,slave2.foo.com, root=slave1.foo.com,slave2.foo.com |
Again, the root option is listed for informational purposes and is not recommended unless necessary.