I want to perform an NFS installation from SuSE-8.0. For this I have 2 computers of which 1 acts as the client and the other as the nfs server. The later gives problems though. When I do an nfs mount it takes a long time before the mount command at the client finishes. As I know that the client (suse-7.3) nfs mounts well on another nfs server it must be due to the nfs server I'm currently configuring. Can somebody provide a hint what can be the cause of the long time before completion? Because of this the NFS installation procedure quits with an error message "nfs server reaction: -1", so I can't executed my desired NFS installation :( Some information that I collected untill now: server: 192.168.3.1 client: 192.168.5.1 server route activated via: ifconfig eth0 192.168.3.1 route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.3.1 eth0 server route activated via: ifconfig eth0 192.168.5.1 route add default eth0 contents /etc/exports: /dist/suse-8.0 *(ro,insecure) /dist/suse-7.2 *(ro) /opt *(ro) /usr *(ro) server log (var/log/messages): Oct 19 00:21:45 dar rpc.mountd: authenticated mount request from 192.168.5.1:696 for /dist/suse-8.0 (/dist/suse-8.0) client log (dmesg): portmap: server localhost not responding, timed out portmap: server localhost not responding, timed out portmap: server localhost not responding, timed out mount command at client: # mount -o ro -t nfs dar:/dist/suse-8.0 /var/adm/dist the command times out after a long time, and than the remote volume has been mounted: # mount proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) shmfs on /dev/shm type shm (rw) /proc/bus/usb on /proc/bus/usb type usbdevfs (rw) dar:/dist/suse-8.0 on /var/adm/dist type nfs (ro,addr=192.168.3.1) ping, ssh to and from the server/client works. http access from the client to the server works. rpcinfo command at client (192.168.3.1): linux:/var/log # rpcinfo -p 192.168.3.1 program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 874 status 100024 1 tcp 876 status 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1024 nlockmgr 100021 3 udp 1024 nlockmgr 100021 4 udp 1024 nlockmgr 100005 1 udp 1026 mountd 100005 1 tcp 1024 mountd 100005 2 udp 1026 mountd 100005 2 tcp 1024 mountd 100005 3 udp 1026 mountd 100005 3 tcp 1024 mountd At the server, the file /var/lib/nfs/xtab has the following (strange) contents: /dist/suse-8.0 192.168.5.1(ro,async,wdelay,hide,insecure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) /dist/suse-7.2 192.168.5.1(ro,async,wdelay,hide,secure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) /dist/suse-7.2 192.168.4.1(ro,async,wdelay,hide,secure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) /opt 192.168.5.1(ro,async,wdelay,hide,secure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) /opt 192.168.0.2(ro,async,wdelay,hide,secure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) /dist/suse-8.0 192.168.5.1(ro,async,wdelay,hide,insecure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) BTW: how can I tidy this? -- Richard Bos Without a home the journey is endless
On Sat, 19 Oct 2002, Richard Bos wrote:
I want to perform an NFS installation from SuSE-8.0...
server: 192.168.3.1 client: 192.168.5.1
server route activated via: ifconfig eth0 192.168.3.1 route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.3.1 eth0
So the client could send ARP to the server, the server could answer back (since ARP doesn't use IP addresses), the client could send a UDP packet to the server's mountd and the server would get it, and the server would send its reply to... itself? And itself would forward the packet to the gateway that handles the 5-net, namely itself. The server reports that it accepted the client's authentication, but the client reports that it never got the filehandle from mountd, which is no lie. I think you want: route add -net 192.168.5.0 netmask 255.255.255.0 dev eth0
server route activated via: ifconfig eth0 192.168.5.1 route add default eth0
Actually the client, right? Assuming that the network has an egress path to the Internet, and that path is on the NFS server (which had better have a good firewall or the hackers are going to chew up its NFS), the client needs to use the egress gateway as its default route. This will also take care of the jump to the rest of the 3-net. Like this (order is important): route add -net 192.168.3.0 netmask 255.255.255.0 dev eth0 route add default gw 192.168.3.1 I don't know your net setup, but it's not common to put two non-interacting subnets on the same Ethernet cable. They still fight for the resource, but don't get the benefit of being able to talk to each other except via a router that's hard to configure. At one time at UCLA we had a ~512 member subnet, using a netmask of 255.255.254.0. If your situation is too many machines that you're unable to split in 2 subnets, you might consider choking down the netmask like that, rather than trying to route traffic for the other net through dev eth0.
At the server, the file /var/lib/nfs/xtab has the following (strange) contents: /dist/suse-8.0 192.168.5.1(ro,async,wdelay,hide,insecure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) ... etc ... BTW: how can I tidy this?
xtab is maintained by the NFS server in its own way, and the sysop should consider it readonly. /etc/exports is what needs to be tidy :-) James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)
Op zaterdag 19 oktober 2002 07:07, schreef Jim Carter:
On Sat, 19 Oct 2002, Richard Bos wrote:
I want to perform an NFS installation from SuSE-8.0...
server: 192.168.3.1 client: 192.168.5.1
I started wrong directly from the beginning, I should have choosen the client and server at the same network. New assignment: server: 192.168.3.1 client: 192.168.3.2 I assume that this makes the configuration easier to understand and at least its more clear to what I want. So, now I thought it will almost work right away, but it still shows the same behaviour :( server: ifconfig eth0 192.168.3.1 route add default eth0 (I removed all the other routes) client: ifconfig eth0 192.168.3.2 route add default eth0 I made no further routing alterations. At the client: # rpcinfo -p 192.168.3.1 shows all the expected output. The command: # mount -o ro -t nfs dar:/dist/suse-8.0 /var/adm/dist takes a very long time to complete, but then at the end the volume is mounted. # dmesg says (for several tries): ortmap: server localhost not responding, timed out portmap: server localhost not responding, timed out lockd_up: makesock failed, error=-5 portmap: server localhost not responding, timed out lockd_down: no lockd running. portmap: server localhost not responding, timed out portmap: server localhost not responding, timed out portmap: server localhost not responding, timed out Oct 19 12:06:11 dar rpc.mountd: authenticated mount request from 192.168.3.2:941 for /dist/suse-8.0 (/dist/suse-8.0) I assume routing is still incorrect, but what is wrong? [continued below]
server route activated via: ifconfig eth0 192.168.3.1 route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.3.1 eth0
So the client could send ARP to the server, the server could answer back (since ARP doesn't use IP addresses), the client could send a UDP packet to the server's mountd and the server would get it, and the server would send its reply to... itself? And itself would forward the packet to the gateway that handles the 5-net, namely itself. The server reports that it accepted the client's authentication, but the client reports that it never got the filehandle from mountd, which is no lie.
I think you want:
route add -net 192.168.5.0 netmask 255.255.255.0 dev eth0
server route activated via: ifconfig eth0 192.168.5.1 route add default eth0
Actually the client, right? Assuming that the network has an egress path to the Internet, and that path is on the NFS server (which had better have a good firewall or the hackers are going to chew up its NFS), the client needs to use the egress gateway as its default route. This will also take care of the jump to the rest of the 3-net. Like this (order is important):
route add -net 192.168.3.0 netmask 255.255.255.0 dev eth0 route add default gw 192.168.3.1
I don't know your net setup, but it's not common to put two non-interacting subnets on the same Ethernet cable. They still fight for the resource, but don't get the benefit of being able to talk to each other except via a router that's hard to configure. At one time at UCLA we had a ~512 member subnet, using a netmask of 255.255.254.0. If your situation is too many machines that you're unable to split in 2 subnets, you might consider choking down the netmask like that, rather than trying to route traffic for the other net through dev eth0.
At the server, the file /var/lib/nfs/xtab has the following (strange) contents: /dist/suse-8.0 192.168.5.1(ro,async,wdelay,hide,insecure,root_squash,no_all_squash,subtr ee_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) ... etc ... BTW: how can I tidy this?
xtab is maintained by the NFS server in its own way, and the sysop should consider it readonly. /etc/exports is what needs to be tidy :-)
Agreed, The /etc/exports is tidy. But all the entries in the xtab file are not relevant anymore. That's the reason if it possible to get it cleaned up, it looks like I confused the nfsserver with my trials :( -- Richard Bos Without a home the journey is endless
After a fustrating evening my to be nfs server is still not communicating with the client. It seems the portmapper at the client is still timing out (according dmesg). A strace on the mount command at the client shows that it stops/hangs here: uname({sys="Linux", node="linux", ...}) = 0 close(3) = 0 close(3) = -1 EBADF (Bad file descriptor) rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV], NULL, 8) = 0 mount("192.168.3.1:/dist/suse-8.0", "/var/adm/dist/", "nfs", 0xc0ed0000, 0x805a560 At this point the file /var/lib/nfs/rmtab at the nfs server shows that the volume has actually be mounted at the client. But the client still don't know... After this point (300 seconds later) the mount goes on with: getcwd("/etc/init.d", 4094) = 12 readlink("/etc/init.d/192.168.3.1:", 0xbfffe4cc, 4095) = -1 ENOENT (No such file or directory) readlink("/var", 0xbfffe4bc, 4095) = -1 EINVAL (Invalid argument) readlink("/var/adm", 0xbfffe4bc, 4095) = -1 EINVAL (Invalid argument) readlink("/var/adm/dist", 0xbfffe4bc, 4095) = -1 EINVAL (Invalid argument) open("/etc/mtab", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3 And after all the volume has been mounted.... I searched google, howto's, other things but I can't find the cause of the this behaviour. Anyone with a clue? # cat /etc/exports: /dist/suse-8.0 linux(rw) /dist/suse-7.2 *() /opt *() /usr *() Op zaterdag 19 oktober 2002 12:22, schreef Richard Bos:
Op zaterdag 19 oktober 2002 07:07, schreef Jim Carter:
On Sat, 19 Oct 2002, Richard Bos wrote:
I want to perform an NFS installation from SuSE-8.0...
server: 192.168.3.1 client: 192.168.5.1
I started wrong directly from the beginning, I should have choosen the client and server at the same network. New assignment:
server: 192.168.3.1 client: 192.168.3.2
[see previous mail] -- Richard Bos Without a home the journey is endless
participants (2)
-
Jim Carter
-
Richard Bos