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@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
