Dear John et al, On Fri, 25 Jun 2004 09:48 pm, John Summerfield wrote: > James Sinnamon wrote: > >Dear list subscribers, > > > >At first I thought my command: > > > > mount -t nfs 192.168.0.6:/etc /mnt/nfs > > > >... had failed. <snip/> > >Eventually, I found, to my surprise, that that the 'mount' command > >had not only withstood all my attempts to smother it, but it also > >succeeded after all. I don't know whether it took 15 minutes > >or two hours, but whatever the time lag was, it it had taken far too > >long. can anyone tell me how to work out what the problem could be? > > > >The entry in 192.168.0.6:/etc/exports is: > > > > /etc 192.168.0.2(ro) > > > >.... where 192.168.0.2 is the nfs client. > > Probably, lockd isn't running on 0.6. lockd handles locking, and if > it's not responding you get these enormous timeouts. > I suppgest you find out why, but since you're mounting ro then this is > acceptable too: > > > mount -t nfs -o nolock 192.168.0.6:/etc /mnt/nfs
The option '-o nolock' works fine, but I will need write access also. lockd not the problem? -------------------------------- I installed the package, nfs_common, which contains rpc.lockd, only to to find out that rpc.lockd was NOT necessary because my kernel (version 2.4.25-1) had a version number greater than 2.4. the nfs_common script doesn not start rpc.lockd. So do I need to enable the kernel's lockd capability or is something else cause the nfs mount to be slow? I will try running rpc.mount and nfs.mountd with verbose flags turned on, but any other suggestions would be welcome. The entry in 192.168.0.6:/etc/exports is still : /etc 192.168.0.2(ro) Thanks again. James -- James Sinnamon jps at westnet com auStralia ph +61 412 319669, +61 2 95692123, +61 2 95726357 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]