NFS through firewall

[Amadeus W. M.]

On Fri, 18 Nov 2005 12:09:28 -0500, James Pifer wrote:

>> Besides the firewall, other things to check for are tcp wrappers
>> (/etc/hosts.allow/deny - I once pulled hair over this one), and permisions
>> of the partitions exported by the NFS server. 
>> 
>> On the client do a 
>> 
>> /usr/sbin/showmount -e nfs.server.com
>> 
>> Whenever you modify something on the nfs server, run 
>> 
>> exportfs -r
>> 
>> or restart the nfs server (better, because it restarts the rpc services
>> too).
>> 
>> 
>> Also, you're not root on the client when you're trying to access the
>> exports, are you? By default, the nfs server does not treat a remote root
>> user as its own root user, for the obvious reasons. So if you're root on
>> the client and try to access an exported partition that belongs to, say,
>> joe/users, you'll get an error.
>> 
>> 
>> Also, the nfs server need not give unrestricted access to a client to
>> access nfs. The problem with nfs and firewall is that the rpc services run
>> on random ports, so the firewall would have to open the same (random)
>> ports to allow access to nfs. Fortunately, nfsd can be configured so that
>> the rpc services run on fixed ports, like so:
>> 
>> On the nfs server:
>> 
>> cat /etc/sysconfig/nfs
>> STATD_PORT=4000
>> LOCKD_TCPPORT=4001
>> LOCKD_UDPPORT=4001
>> MOUNTD_PORT=4002
>> RQUOTAD_PORT=4003
>> 
>> Still on the nfs server, in /etc/sysconfig/iptables put these rules:
>> 
>> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 2049 -j ACCEPT-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 111 -j ACCEPT
>> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT
>> -A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 4000:4003 -j ACCEPT
>> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 4000:4003 -j ACCEPT
>> 
>> These will allow anything to access the nfs/rpc ports. To allow a
>> only single machine, add its address to these rules.
>> 
>> 
> 
> Yes, I am root on the client. I do this all the time with my other
> fedora boxes. For that matter, to use mount I have to be root. I don't
> understand this part.
> 
> I will try to set fixed ports and see if that helps. 
> 
> Thanks,
> James


Below 

phoenix = client
orion = nfs server

When I try, as root on the client, to access a (directory) on an nfs
partition, I get this error:

[root at phoenix home]# cd /net/orion/home/amadeus/
-bash: cd: /net/orion/home/amadeus/: Permission denied

So this is not your problem (yet), but let me explain it anyway. 

If the NFS server treated a client root as its own root,
then the remote root could wreck havoc on the nfs server. So by default,
the nfs server treats a client root as any mortal user (world). 

In the example above, the /home/amadeus directory on the NFS server
(here mounted as /net/orion/home/amadeus) only belongs to amadeus/users so
only user amadeus (on the client) can access it; client roots can't,
because they are world.


You don't have to mount the nfs partition manually, but rather you can let
the automounter do so. This happens automatically, when somebody is trying
to access the partition. FC4 is set up very nicely (the /etc/auto.master
and /etc/auto.net), and you literally don't have to do any extra
configuration (like /etc/fstab), just start the automounter (autofs). 

Anyway, the rpc error you're getting is probably due to the fact that your
client can't talk to the nfs server, so it's a firewall/tcp wrappers
problem, or the nfs partitions are not exported to your machine. Tell the
admin of the nfs server to check the /etc/hosts.deny file and the
/etc/exports file, or better yet, do so yourself if you can ssh. 

On the client, try 

/usr/sbin/showmount -e nfs.server.com
/usr/sbin/rpcinfo -p nfs.server.com

and even 

telnet nfs.server.com 2049
telnet nfs.server.com 111