[Gllug] NFS across firewall

Xander D Harkness xander at harkness.co.uk
Mon Jun 9 12:58:29 UTC 2003


On Monday 09 June 2003 12:39, Richard Turner wrote:
> > This is from the O'Reilly NIS / NFS book:
> >
> > mount command
> > mount -o proto=tcp,public nfs.eisler.com:/export/home/mre /mre
> >
> > This is after allowing tcp port 2049 in your firewall
> >
> > The proto=tcp  option forces mount to use the TCP/IP protocol.
>
> Firewalls
>
> > prefer to deal with TCP because it establishs the state that the
>
> firewall
>
> > can
> > use to know if a TCP segment from the outside is a response from an
> > external
> > server or a call from an external client.
> >
> > The 'public' option does the following:
> >
> > Bypasses the portmapper entirely and always contacts the NFS server
>
> port
>
> > on
> > 2049 (or a different port if the port= option is specified to the
>
> mount
>
> > command)  It sends a NULL ping to the NFS Version 3 server first, and
>
> if
>
> > that
> > fails, tries the NFS Version 2 server next.
> >
> > Makes the NFS client contact the NFS server directory to get an
>
> initial
>
> > file
> > handle
> >
> > Marks the NFS mounts with the llock option.  This is an undocumented
>
> mount
>
> > option that says to handle all locking requests for the file on the
>
> NFS
>
> > filesystem locally.
> >
> > Please also note that while the NFS server normally listens on 2049
>
> you
>
> > can
> > specify when you start the NFS server to listen only for TCP rather
>
> than
>
> > UDP
> > and TCP, and lock it to a specific port.
>
> Xander, you're a star!  Thanks for this.
>
> Incidentally, since I don't have O'Reilly's NIS / NFS book, where else
> might I have found this information?  I do try to find stuff out for
> myself before asking, (dreading the 'RTFM' response!), but had no joy
> this time.

Mount options for nfs
       Instead of a textual option string, parsed by the kernel, the nfs  file
       system  expects  a  binary argument of type struct nfs_mount_data.  The
       program  mount  itself  parses  the  following  options  of  the   form
       `tag=value',  and  puts  them  in  the  structure  mentioned:  rsize=n,
       wsize=n,  timeo=n,  retrans=n,  acregmin=n,   acregmax=n,   acdirmin=n,
       acdirmax=n,  actimeo=n,  retry=n,  port=n, mountport=n, mounthost=name,
       mountprog=n, mountvers=n, nfsprog=n, nfsvers=n, namlen=n.   The  option
       addr=n  is  accepted  but ignored.  Also the following Boolean options,
       possibly preceded by no are  recognized:  bg,  fg,  soft,  hard,  intr,
       posix, cto, ac, tcp, udp, lock.  For details, see nfs(5).

The options here for Linux include tcp as a boolean option, rather than proto.  
There are therefore some differences between that and Solaris, which I 
believe I quoted earlier.  By saying check the Docs, it was not a RTFM, it 
was take this information and build on it with what you find in the docs :-)

Kind regards
Xander

       Especially useful options include

       rsize=8192,wsize=8192
              This  will make your nfs connection faster than with the default
              buffer size of 4096. (NFSv2 does not work with larger values  of
              rsize and wsize.)

       hard   The  program  accessing a file on a NFS mounted file system will
              hang when the server crashes. The process cannot be  interrupted
              or  killed unless you also specify intr.  When the NFS server is
              back online the program will continue undisturbed from where  it
              was. This is probably what you want.

       soft   This  option  allows the kernel to time out if the nfs server is
              not responding for some time. The time  can  be  specified  with
              timeo=time.   This  option  might  be  useful if your nfs server
              sometimes doesn't respond or will be rebooted while some process
              tries  to  get  a  file from the server.  Usually it just causes
              lots of trouble.

       nolock Do not use locking. Do not start lockd


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list