I had Debian Lenny with an NFS share set up that my Windows 7 machine could access using the Windows 7 NFS client. I updated Lenny to Squeeze and now Windows cannot access it. It just sits there for a while and then says it cannot find the path. I haven't changed anything in the setup. The exports entry is wide open and set with the options:

*(ro,no_subtree_check,insecure,all_squash)

Any ideas??

jj

Maybe the NFS version changed, try running the following on the server:
You'll see the version numbers in column 2 .. it may be that the default version is now 4 and Windows can't handle it, you can disable nfs v4 by editing adding "-N 4" to rpc.nfsd startup options.

Ran the above and I get:

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 55185 status
100024 1 tcp 38232 status
100021 1 udp 46554 nlockmgr
100021 3 udp 46554 nlockmgr
100021 4 udp 46554 nlockmgr
100021 1 tcp 50315 nlockmgr
100021 3 tcp 50315 nlockmgr
100021 4 tcp 50315 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 35431 mountd
100005 1 tcp 38384 mountd
100005 2 udp 35431 mountd
100005 2 tcp 38384 mountd
100005 3 udp 35431 mountd
100005 3 tcp 38384 mountd

If I understand what you have said, it is running versions 2, 3, and 4? I'm not sure where to find the rpc.nfsd startup options.

jj

Correct, it's running 2, 3 and 4 - the problem is that it will usually offer the highest version first unless the client specifically mentions the version it wants, and I don't know whether that's possible with the Windows client.

I haven't run Debian in the last decade but going by this, you may have to add the option to RPCNFSDCOUNT in /etc/default/nfs-kernel-server, something like:

It could also be worth seeing if you can force the NFS version in the Windows client..

Thanks for the suggestion - alas, tried it and no change. I have also tried a different Windows machine, to make sure it wasn't the machine. The Windows client has very little you can set. The only page of some possible interest is the Security page, which can set any of sys, krb5, krb5i - and is set to use reserved ports. I tried turning off Kerberos - no dice - tried turning off 'reserved ports,' ditto.

This is becoming maddening! It worked fine before!

jj

Back to basics then: is the IP address of the NFS server still the same? Can you access the NFS share from another Linux machine? Can you ping the NFS server from the Win-OS machine? Is there (now) a firewall getting in the way? You may want to re-generate (and copy over) the ssh keys, it has probably changed on the server due to its upgrade.

Back to basics then: is the IP address of the NFS server still the same?

Yes

Can you access the NFS share from another Linux machine?

Haven't a Linux machine to try from at the moment but that is something I am going to give a go

Can you ping the NFS server from the Win-OS machine?

Yes

Is there (now) a firewall getting in the way?

No (neither end - and tried with two Windows machines)

You may want to re-generate (and copy over) the ssh keys, it has probably changed on the server due to its upgrade

OK - though I confess I am only vaguely aware how to do this, and especially where to put them on the Windows machine. But I had thought that the 'sys' method of security (see above about the Windows client) wouldn't be using them. And one of the Windows machines had never tried to connect to the NFS server before.

By the way, I can putty to the machine just fine from either Windows machine - and putty doesn't ask me if I trust the Linux machine - so it seems to me likely that the SSH keys are all happy.

I will try to find another Linux machine to connect to the NFS share with.

jj

Right, that means the cause is indeed in the NFS configuration. Sometimes systematically eliminating causes can be the only way to solving the problem... :-\

As for another Linux machine: reboot one of the Win-OS machines with a Linux Live-CD, like Knoppix. Doesn't install anything to disk, unless you explicitly tell it do so...

Right, that means the cause is indeed in the NFS configuration. Sometimes systematically eliminating causes can be the only way to solving the problem... :-\

Absolutely! I am 100% with you there.

Yes, going to have to do that to eliminate a problem with Windows. And if it does prove to be Windows, then I will have to use something else - maybe WinSCP - to copy data. NFS was so nice and convenient :-)

Thanks for all the help. I will report back when I have tried a test from Linux.

jj

Windows is the problem. I found a Linux machine and can connect just fine.

Sigh!

jj

NFS is a Unix (and Linux) oriented file system, Win-OS has SMB (Samba to you and me) so try that for starters.

Yes - I have in the past, on a different Linux system, successfully set up Samba - but it was a real pain, and the more so because my Windows boxes are part of an Active Directory. With this new Linux machine - a little laptop with only command-line interface (no X), I had set up NFS so that my Windows machine could backup the data from it. It worked a charm - until I upgraded to Squeeze :-( I may try to set up Samba - but WinSCP is something I have used in the past as well. It's less convenient than just having a share connected, but might be easier to set up than Samba.

jj