NFS Howto Interop
From Linux NFS
(→SunOS) |
|||
(3 intermediate revisions not shown) | |||
Line 1: | Line 1: | ||
- | + | ==== Using Linux NFS with Other OSes==== | |
+ | Every operating system, Linux included, has quirks and deviations in the behavior of its NFS implementation -- sometimes because the protocols are vague, sometimes because they leave gaping security holes. Linux will work properly with all major vendors' NFS implementations, as far as we know. However, there may be extra steps involved to make sure the two OSes are communicating clearly with one another. This section details those steps. | ||
+ | |||
+ | In general, it is highly ill-advised to attempt to use a Linux machine with a kernel before 2.2.18 as an NFS server for non-Linux clients. Implementations with older kernels may work fine as clients; however if you are using one of these kernels and get stuck, the first piece of advice we would give is to upgrade your kernel and see if the problems go away. The user-space NFS implementations also do not work well with non-Linux clients. | ||
+ | |||
+ | Following is a list of known issues for using Linux together with major operating systems. | ||
+ | ===== AIX ===== | ||
+ | '''AIX Servers'''<br/> | ||
+ | The format for the /etc/exports file for our example in [[NFS_Howto_Server|NFS Howto: Server Setup]] is: | ||
+ | <pre> | ||
+ | /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 | ||
+ | </pre> | ||
+ | '''AIX Clients'''<br/> | ||
+ | AIX uses the file ''/etc/filesystems'' instead of ''/etc/fstab''. A sample entry, based on the example in [[NFS_Howto_Client|NFS Howto: Client]] looks like this: | ||
+ | <pre> | ||
+ | /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 | ||
+ | </pre> | ||
+ | *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. | ||
+ | ===== BSD ===== | ||
+ | '''BSD Servers and Linux Clients'''<br/> | ||
+ | BSD kernels tend to work better with larger block sizes.<br/> | ||
+ | '''Linux Servers and BSD Clients'''<br/> | ||
+ | Some versions of BSD may make requests to the server from insecure ports, in which case you will need to export your volumes with the '''insecure''' option. See the man page for'' exports(5)'' for more details. | ||
+ | ===== Tru64 Unix ===== | ||
+ | '''Tru64 UNIX Servers with Linux Clients'''<br/> | ||
+ | n general, Tru64 Unix servers work quite smoothly with Linux clients. The format for the /etc/exports file for our example in [[NFS_Howto_Server|NFS Howto: Server Setup]] is: | ||
+ | <pre> | ||
+ | /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 | ||
+ | </pre> | ||
+ | (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. | ||
+ | '''Linux Servers and Tru64 Unix Clients'''<br/> | ||
+ | There are two issues to watch out for here. First, Tru64 Unix mounts using Version 3 NFS by default. You will see mount errors if your Linux server does not support Version 3 NFS. Second, in Tru64 Unix 4.x, NFS locking requests are made by ''daemon''. You will therefore need to specify the '''insecure_locks''' option on all volumes you export to a Tru64 Unix 4.x client; see the '''exports''' man pages for details. | ||
+ | ===== HP-UX ===== | ||
+ | '''HP-UX Servers and Linux Clients'''<br/> | ||
+ | A sample ''/etc/exports'' entry on HP-UX looks like this: | ||
+ | <pre> | ||
+ | /usr -ro,access=slave1.foo.com:slave2.foo.com | ||
+ | /home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com | ||
+ | </pre> | ||
+ | (The '''root''' option is listed in the last entry for informational purposes only; its use is not recommended unless necessary.) | ||
+ | '''Linux Servers and HP-UX Clients''' | ||
+ | HP-UX diskless clients will require at least a kernel version 2.2.19 (or patched 2.2.18) for device files to export correctly. Also, any exports to an HP-UX client will need to be exported with the '''insecure_locks''' option. | ||
+ | ===== IRIX ===== | ||
+ | '''IRIX Servers and Linux Clients'''<br/> | ||
+ | A sample ''/etc/exports'' entry on HP-UX looks like this: | ||
+ | <pre> | ||
+ | /usr -ro,access=slave1.foo.com:slave2.foo.com | ||
+ | /home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com | ||
+ | </pre> | ||
+ | (The '''root''' option is listed in the last entry for informational purposes only; its use is not recommended unless necessary.) | ||
+ | |||
+ | There are reportedly problems when using the nohide option on exports to linux 2.2-based systems. This problem is fixed in the 2.4 kernel. As a workaround, you can export and mount lower-down file systems separately. | ||
+ | |||
+ | As of Kernel 2.4.17, there continue to be several minor interoperability issues that may require a kernel upgrade. In particular: | ||
+ | *Make sure that Trond Myklebust's seekdir (or dir) kernel patch is applied. The latest version (for 2.4.17) is located [http://www.fys.uio.no/~trondmy/src/2.4.17/linux-2.4.17-seekdir.dif here]. | ||
+ | *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 to correct this problem is available [http://www.geocrawler.com/lists/3/SourceForge/789/0/7777454/ here]. | ||
+ | *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 [http://www.geocrawler.com/archives/3/789/2001/9/100/6531172/ here]. The naming vesion can be found by using the command: '''xfs_growfs -n mount_point'''. A workaround to this problem 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. | ||
+ | '''IRIX clients and Linux servers'''<br/> | ||
+ | rix versions up to 6.5.12 have problems mounting file systems exported from Linux boxes - the mount point "gets lost," e.g., | ||
+ | <pre> | ||
+ | # mount linux:/disk1 /mnt | ||
+ | # cd /mnt/xyz/abc | ||
+ | # pwd | ||
+ | /xyz/abc | ||
+ | </pre> | ||
+ | This is known IRIX bug (SGI bug 815265 - IRIX not liking file handles of less than 32 bytes), which is fixed in IRIX 6.5.13. If it is not possible to upgrade to IRIX 6.5.13, then the unofficial workaround is to force the Linux '''nfsd''' to always use 32 byte file handles. A number of patches for this issue exist [http://www.geocrawler.com/archives/3/789/2001/8/50/6371896/ here] and [http://oss.sgi.com/projects/xfs/mail_archive/0110/msg00006.html here]. | ||
+ | ===== Solaris ===== | ||
+ | '''Solaris Servers and Linux Clients'''<br/> | ||
+ | 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 [[NFS_Howto_Server|NFS Howto: Server Setup]] would look like: | ||
+ | <pre> | ||
+ | share -o rw=slave1,slave2 -d "Master Usr" /usr | ||
+ | </pre> | ||
+ | and instead of running '''exportfs''' after editing, you run '''shareall'''. | ||
+ | |||
+ | 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 and Linux Servers'''<br/> | ||
+ | Solaris clients will regularly produce the following message: | ||
+ | <pre> | ||
+ | svc: unknown program 100227 (me 100003) | ||
+ | </pre> | ||
+ | This happens because Solaris clients, when they mount, try to obtain ACL information - which Linux obviously does not have. The messages can safely be ignored. | ||
+ | |||
+ | There are two known issues with diskless Solaris clients: First, a kernel version of at least 2.2.19 is needed to get ''/dev/null'' to export correctly. Second, the packet size may need to be set extremely small (i.e., 1024) on diskless sparc clients because the clients do not know how to assemble packets in reverse order. This can be done from ''/etc/bootparams'' on the clients. | ||
+ | ===== SunOS ===== | ||
+ | SunOS only has NFS Version 2 over UDP. | ||
+ | '''SunOS Servers and Linux Clients'''<br/> | ||
+ | On the server end, SunOS uses the most traditional format for its /etc/exports file. The example in [[NFS_Howto_Server|NFS Howto: Server Setup]] would look like: | ||
+ | <pre> | ||
+ | /usr -access=slave1.foo.com,slave2.foo.com | ||
+ | /home -rw=slave1.foo.com,slave2.foo.com, root=slave1.foo.com,slave2.foo.com | ||
+ | </pre> | ||
+ | Again, the root option is listed for informational purposes and is not recommended unless necessary. | ||
+ | |||
+ | '''SunOS Clients and Linux Servers'''<br/> | ||
+ | Be advised that SunOS makes all NFS locking requests as daemon, and therefore you will need to add the '''insecure_locks''' option to any volumes you export to a SunOS machine. See the '''exports''' man page for details. |
Latest revision as of 14:30, 6 April 2006
Contents |
Using Linux NFS with Other OSes
Every operating system, Linux included, has quirks and deviations in the behavior of its NFS implementation -- sometimes because the protocols are vague, sometimes because they leave gaping security holes. Linux will work properly with all major vendors' NFS implementations, as far as we know. However, there may be extra steps involved to make sure the two OSes are communicating clearly with one another. This section details those steps.
In general, it is highly ill-advised to attempt to use a Linux machine with a kernel before 2.2.18 as an NFS server for non-Linux clients. Implementations with older kernels may work fine as clients; however if you are using one of these kernels and get stuck, the first piece of advice we would give is to upgrade your kernel and see if the problems go away. The user-space NFS implementations also do not work well with non-Linux clients.
Following is a list of known issues for using Linux together with major operating systems.
AIX
AIX Servers
The format for the /etc/exports file for our example in NFS Howto: Server Setup 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 Clients
AIX uses the file /etc/filesystems instead of /etc/fstab. A sample entry, based on the example in NFS Howto: Client 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.
BSD
BSD Servers and Linux Clients
BSD kernels tend to work better with larger block sizes.
Linux Servers and BSD Clients
Some versions of BSD may make requests to the server from insecure ports, in which case you will need to export your volumes with the insecure option. See the man page for exports(5) for more details.
Tru64 Unix
Tru64 UNIX Servers with Linux Clients
n general, Tru64 Unix servers work quite smoothly with Linux clients. The format for the /etc/exports file for our example in NFS Howto: Server Setup 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.
Linux Servers and Tru64 Unix Clients
There are two issues to watch out for here. First, Tru64 Unix mounts using Version 3 NFS by default. You will see mount errors if your Linux server does not support Version 3 NFS. Second, in Tru64 Unix 4.x, NFS locking requests are made by daemon. You will therefore need to specify the insecure_locks option on all volumes you export to a Tru64 Unix 4.x client; see the exports man pages for details.
HP-UX
HP-UX Servers and Linux Clients
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
(The root option is listed in the last entry for informational purposes only; its use is not recommended unless necessary.) Linux Servers and HP-UX Clients HP-UX diskless clients will require at least a kernel version 2.2.19 (or patched 2.2.18) for device files to export correctly. Also, any exports to an HP-UX client will need to be exported with the insecure_locks option.
IRIX
IRIX Servers and Linux Clients
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
(The root option is listed in the last entry for informational purposes only; its use is not recommended unless necessary.)
There are reportedly problems when using the nohide option on exports to linux 2.2-based systems. This problem is fixed in the 2.4 kernel. As a workaround, you can export and mount lower-down file systems separately.
As of Kernel 2.4.17, there continue to be several minor interoperability issues that may require a kernel upgrade. In particular:
- Make sure that Trond Myklebust's seekdir (or dir) kernel patch is applied. The latest version (for 2.4.17) is located here.
- 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 to correct this problem is available here.
- 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 here. The naming vesion can be found by using the command: xfs_growfs -n mount_point. A workaround to this problem 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.
IRIX clients and Linux servers
rix versions up to 6.5.12 have problems mounting file systems exported from Linux boxes - the mount point "gets lost," e.g.,
# mount linux:/disk1 /mnt # cd /mnt/xyz/abc # pwd /xyz/abc
This is known IRIX bug (SGI bug 815265 - IRIX not liking file handles of less than 32 bytes), which is fixed in IRIX 6.5.13. If it is not possible to upgrade to IRIX 6.5.13, then the unofficial workaround is to force the Linux nfsd to always use 32 byte file handles. A number of patches for this issue exist here and here.
Solaris
Solaris Servers and Linux Clients
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 NFS Howto: Server Setup would look like:
share -o rw=slave1,slave2 -d "Master Usr" /usr
and instead of running exportfs after editing, you run shareall.
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 and Linux Servers
Solaris clients will regularly produce the following message:
svc: unknown program 100227 (me 100003)
This happens because Solaris clients, when they mount, try to obtain ACL information - which Linux obviously does not have. The messages can safely be ignored.
There are two known issues with diskless Solaris clients: First, a kernel version of at least 2.2.19 is needed to get /dev/null to export correctly. Second, the packet size may need to be set extremely small (i.e., 1024) on diskless sparc clients because the clients do not know how to assemble packets in reverse order. This can be done from /etc/bootparams on the clients.
SunOS
SunOS only has NFS Version 2 over UDP.
SunOS Servers and Linux Clients
On the server end, SunOS uses the most traditional format for its /etc/exports file. The example in NFS Howto: Server Setup 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.
SunOS Clients and Linux Servers
Be advised that SunOS makes all NFS locking requests as daemon, and therefore you will need to add the insecure_locks option to any volumes you export to a SunOS machine. See the exports man page for details.