On Sun, 2005-04-24 at 20:28 +0200, Angelo Machils wrote:

Hello there!

Perhaps this is a little off-topic, but I notice this only on the Centos box. I'm running Centos 4 on an AMD64 which has the following entries in the fstab to connect to NFS shares on a Fedora3 box: 192.168.1.12:/home/angelo/ /home/angelo/NFS_share1 nfs rw,addr=192.168.1.12 0 0 192.168.1.12:/home/angelo/data /home/angelo/NFS_share2 nfs rw,addr=192.168.1.12 0 0 192.168.1.12:/home/angelo/data2 /home/angelo/NFS_share3 nfs rw,addr=192.168.1.12 0 0 I have opened ports 111 (TCP), 648 (TCP), 651 (TCP) and 2049 (TCP and UDP) in iptables on the FC3 box and I can connect to them, but after a while I seem to loose the connection to the shares. When I try to move into them while in a console I get the error: bash: cd: NFS_share1: Input/output error In Nautilus I don't even see the directories anymore and in /var/log/messages I get this error msgs: Apr 24 20:17:02 solaris kernel: RPC: garbage, exit EIO There are not entries in the /var/log/messages on the FC3 box. If I manually umount them and then mount them again, I can use them again for a while.... The exports file on the FC3 box looks like this: [root@imhotep etc]# more exports /home/angelo 192.168.1.*(rw,sync) /home/angelo/data 192.168.1.*(rw,sync) /home/angelo/data2 192.168.1.*(rw,sync)

Anyone any idea what is wrong here?

Angelo-

I have found that you need to allow higher numbered tcp ports (32768:65535) through on both the server and client to make rpc connections happy. I have also had to allow a range of ports in between 600:1024 UDP range on the server to make things happy (though, this was with older NFS implementations). It's possible that you need to open up more ports on the server. One thing to do would be to add a log rule to your iptables rules on the client and server and see what is being dropped when the client mount hangs.

Sean

Angelo Machils wrote:

Hello there!

Perhaps this is a little off-topic, but I notice this only on the Centos box. I'm running Centos 4 on an AMD64 which has the following entries in the fstab to connect to NFS shares on a Fedora3 box:

I have opened ports 111 (TCP), 648 (TCP), 651 (TCP) and 2049 (TCP and UDP) in iptables on the FC3 box and I can connect to them, but after a while I seem to loose the connection to the shares.

NFS uses RPC, and RPC can be a real bitch to get it working over a firewall. IMO, if anybody thinks of writing a service that uses RPC, he/she should think again. And again, until he/she drops the idea, and decides not to use RPC.

Anyhow, since NFS does use RPC, and we are kind of stuck with it for now... Try and make sure that in all of your configuration files all NFS RPC services are set up to use fixed ports, and make sure all of them are covered. If you miss single one, you get into trouble. The other solution is to open all high ports from the client to the server, and see if that helps. Try using rpcinfo (or wahtever it is called) utility and see if port mapper assigned any non-standard ports to any of NFS related RPC services.

Also, put some logging rules into your firewall configuration. That will help you troubleshoot the problems. When you do it, you'll know exactly what kind of packets are being dropped by the firewall and why they are dropped. Then you can either update your firewall configuration or make changes on NFS/RPC (for example, if you missed to explicitly force some NFS related RPC service to use fixed port).

There's also RPC helper module for Netfilter. It is part of iptables package, but not part of the kernel package (in other words, you can't use it, unless you recompile the kernel, and than you need to know exactly what patch level of the module was in iptables package to patch the kernel with the same patch level of the module, or you need to repatch/recompile both iptables and the kernel). Adding Netfilter patches to your kernel can be a real bitch too for unexperienced users. Wish there was an easier way of doing it (as in here's the userland module, here's the kernel module, just compile these too, but there isn't). I've attempted to try it out once long time ago, but it wasn't working all that great for me. Hopefully it will mature one day and will be included into the kernel.