Old DOS NFS client won't talk to Linux NFS server
Greetings, all. I'm wondering if someone may have some insight in to an NFS related problem. I have an embedded system running Linux. I set it as an NFS server. I have been able to have the server mount its own share and I have also been able to mount the share on my desktop. That tells me the NFS configuration is fundamentally working. The problem is when I try to mount the from an old industrial system running Hummingbird NFS Maestro DOS based software from 1997. That system is able to ping the server so I know it has a network connection. However, when the "nfs link Z: \\192.168.100.110\/share" command is issue I just get the message on the server saying "No response from server". The Linux NFS server is supposed to support NFS v2 through v4. The old system is probably v3 at best and the logs only seem to indicate v2. I haven't figured out how to disable v4 support on the NFS server. I used tshark to capture the NFS traffic. When the "exports" command was issued on the old machine: 909 873.726802357 192.168.100.101 → 192.168.100.110 Portmap 98 V2 GETPORT Call MOUNT(100005) V:1 UDP 910 873.727576161 192.168.100.110 → 192.168.100.101 Portmap 70 V2 GETPORT Reply (Call In 909) Port:53625 911 873.728326009 192.168.100.101 → 192.168.100.110 MOUNT 110 V1 EXPORT Call 912 873.731315731 192.168.100.110 → 192.168.100.101 MOUNT 142 V1 EXPORT Reply (Call In 911) When the "nfs link" command was issued on the old machine: 915 929.199301001 192.168.100.101 → 192.168.100.110 Portmap 98 V2 GETPORT Call HCLNFSD(788585389) V:1 UDP 916 929.199993392 192.168.100.110 → 192.168.100.101 Portmap 70 V2 GETPORT Reply (Call In 915) PROGRAM_NOT_AVAILABLE 917 929.200757113 192.168.100.101 → 192.168.100.110 Portmap 98 [RPC retransmission of #915]V2 GETPORT Call (Reply In 916) HCLNFSD(788585389) V:1 UDP 918 929.201092226 192.168.100.110 → 192.168.100.101 Portmap 70 [RPC duplicate of #916]V2 GETPORT Reply (Call In 915) PROGRAM_NOT_AVAILABLE 919 929.201744034 192.168.100.101 → 192.168.100.110 Portmap 98 [RPC retransmission of #915]V2 GETPORT Call (Reply In 916) PCNFSD(150001) V:2 UDP The output from rpcinfo is: $ rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 57318 status 100024 1 tcp 46225 status 100005 1 udp 53625 mountd 100005 1 tcp 40199 mountd 100005 2 udp 53980 mountd 100005 2 tcp 53443 mountd 100005 3 udp 50848 mountd 100005 3 tcp 49067 mountd 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 2 tcp 2049 100227 3 tcp 2049 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100227 2 udp 2049 100227 3 udp 2049 100021 1 udp 42943 nlockmgr 100021 3 udp 42943 nlockmgr 100021 4 udp 42943 nlockmgr 100021 1 tcp 44539 nlockmgr 100021 3 tcp 44539 nlockmgr 100021 4 tcp 44539 nlockmgr Is the DOS based NFS client compatible with current day Linux NFS server? Any idea why I see messages saying PROGRAM_NOT_AVAILABLE? If something is supposedly missing, what program is it looking for? It would have been a lot more helpful if whatever program is reporting a "missing program" said what program it couldn't find, or couldn't talk to. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick
I was all set to say "well, obviously", but ... On my ubuntu desktop, nfs(5) tells me that mount.nfs(8) will take an nfsvers=2 option. I wonder if your desktop did the mount with the default version 4? Did you try forcing a mount from your desktop with nfsvers=2? My man pages seemed to suggest that mountd was only needed for NFS 2 and 3 - could there be firewall settings on your embedded NFS server blocking some traffic from the DOS client? The PROGRAM_NOT_AVAILABLE makes me wonder if the portmapper lookup by the DOS client didn't find what it wanted, or was blocked? It looks like your server is listening both tcp and udp which is likely good. Hope that's helpful ... John On Tue, 2022/06/28 04:11:57PM -0400, Kevin Cozens via talk <talk@gtalug.org> wrote: | Greetings, all. | | I'm wondering if someone may have some insight in to an NFS related problem. | | I have an embedded system running Linux. I set it as an NFS server. I have | been able to have the server mount its own share and I have also been able | to mount the share on my desktop. That tells me the NFS configuration is | fundamentally working. | | The problem is when I try to mount the from an old industrial system running | Hummingbird NFS Maestro DOS based software from 1997. That system is able to | ping the server so I know it has a network connection. However, when the | "nfs link Z: \\192.168.100.110\/share" command is issue I just get the | message on the server saying "No response from server". | | The Linux NFS server is supposed to support NFS v2 through v4. The old | system is probably v3 at best and the logs only seem to indicate v2. I | haven't figured out how to disable v4 support on the NFS server. I used | tshark to capture the NFS traffic. | | When the "exports" command was issued on the old machine: | | 909 873.726802357 192.168.100.101 → 192.168.100.110 Portmap 98 V2 GETPORT | Call MOUNT(100005) V:1 UDP | 910 873.727576161 192.168.100.110 → 192.168.100.101 Portmap 70 V2 GETPORT | Reply (Call In 909) Port:53625 | 911 873.728326009 192.168.100.101 → 192.168.100.110 MOUNT 110 V1 EXPORT Call | 912 873.731315731 192.168.100.110 → 192.168.100.101 MOUNT 142 V1 EXPORT | Reply (Call In 911) | | | When the "nfs link" command was issued on the old machine: | | 915 929.199301001 192.168.100.101 → 192.168.100.110 Portmap 98 V2 GETPORT | Call HCLNFSD(788585389) V:1 UDP | 916 929.199993392 192.168.100.110 → 192.168.100.101 Portmap 70 V2 GETPORT | Reply (Call In 915) PROGRAM_NOT_AVAILABLE | 917 929.200757113 192.168.100.101 → 192.168.100.110 Portmap 98 [RPC | retransmission of #915]V2 GETPORT Call (Reply In 916) HCLNFSD(788585389) V:1 | UDP | 918 929.201092226 192.168.100.110 → 192.168.100.101 Portmap 70 [RPC | duplicate of #916]V2 GETPORT Reply (Call In 915) PROGRAM_NOT_AVAILABLE | 919 929.201744034 192.168.100.101 → 192.168.100.110 Portmap 98 [RPC | retransmission of #915]V2 GETPORT Call (Reply In 916) PCNFSD(150001) V:2 UDP | | | The output from rpcinfo is: | | $ rpcinfo -p | program vers proto port service | 100000 4 tcp 111 portmapper | 100000 3 tcp 111 portmapper | 100000 2 tcp 111 portmapper | 100000 4 udp 111 portmapper | 100000 3 udp 111 portmapper | 100000 2 udp 111 portmapper | 100024 1 udp 57318 status | 100024 1 tcp 46225 status | 100005 1 udp 53625 mountd | 100005 1 tcp 40199 mountd | 100005 2 udp 53980 mountd | 100005 2 tcp 53443 mountd | 100005 3 udp 50848 mountd | 100005 3 tcp 49067 mountd | 100003 2 tcp 2049 nfs | 100003 3 tcp 2049 nfs | 100003 4 tcp 2049 nfs | 100227 2 tcp 2049 | 100227 3 tcp 2049 | 100003 2 udp 2049 nfs | 100003 3 udp 2049 nfs | 100227 2 udp 2049 | 100227 3 udp 2049 | 100021 1 udp 42943 nlockmgr | 100021 3 udp 42943 nlockmgr | 100021 4 udp 42943 nlockmgr | 100021 1 tcp 44539 nlockmgr | 100021 3 tcp 44539 nlockmgr | 100021 4 tcp 44539 nlockmgr | | | Is the DOS based NFS client compatible with current day Linux NFS server? | Any idea why I see messages saying PROGRAM_NOT_AVAILABLE? | If something is supposedly missing, what program is it looking for? It would | have been a lot more helpful if whatever program is reporting a "missing | program" said what program it couldn't find, or couldn't talk to. | | -- | Cheers! | | Kevin. | | http://www.ve3syb.ca/ | "Nerds make the shiny things that | https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | | that's why we're powerful" | Owner of Elecraft K2 #2172 | | #include <disclaimer/favourite> | --Chris Hardwick | --- | Post to this mailing list talk@gtalug.org | Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On 2022-06-28 17:33, John Sellens wrote:
On my ubuntu desktop, nfs(5) tells me that mount.nfs(8) will take an nfsvers=2 option.
I wonder if your desktop did the mount with the default version 4? Did you try forcing a mount from your desktop with nfsvers=2?
I haven't tried that but I can see what happens.
My man pages seemed to suggest that mountd was only needed for NFS 2 and 3 - could there be firewall settings on your embedded NFS server blocking some traffic from the DOS client?
The age of the NFS client software predates NFS v4. There is currently no firewall in use so that isn't an issue.
Hope that's helpful ...
Thanks, John. I think the message from Lennart has gotten to the root of the issue. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick
On Tue, Jun 28, 2022 at 04:11:57PM -0400, Kevin Cozens via talk wrote:
Greetings, all.
I'm wondering if someone may have some insight in to an NFS related problem.
I have an embedded system running Linux. I set it as an NFS server. I have been able to have the server mount its own share and I have also been able to mount the share on my desktop. That tells me the NFS configuration is fundamentally working.
The problem is when I try to mount the from an old industrial system running Hummingbird NFS Maestro DOS based software from 1997. That system is able to ping the server so I know it has a network connection. However, when the "nfs link Z: \\192.168.100.110\/share" command is issue I just get the message on the server saying "No response from server".
The Linux NFS server is supposed to support NFS v2 through v4. The old system is probably v3 at best and the logs only seem to indicate v2. I haven't figured out how to disable v4 support on the NFS server. I used tshark to capture the NFS traffic.
When the "exports" command was issued on the old machine:
909 873.726802357 192.168.100.101 → 192.168.100.110 Portmap 98 V2 GETPORT Call MOUNT(100005) V:1 UDP 910 873.727576161 192.168.100.110 → 192.168.100.101 Portmap 70 V2 GETPORT Reply (Call In 909) Port:53625 911 873.728326009 192.168.100.101 → 192.168.100.110 MOUNT 110 V1 EXPORT Call 912 873.731315731 192.168.100.110 → 192.168.100.101 MOUNT 142 V1 EXPORT Reply (Call In 911)
When the "nfs link" command was issued on the old machine:
915 929.199301001 192.168.100.101 → 192.168.100.110 Portmap 98 V2 GETPORT Call HCLNFSD(788585389) V:1 UDP 916 929.199993392 192.168.100.110 → 192.168.100.101 Portmap 70 V2 GETPORT Reply (Call In 915) PROGRAM_NOT_AVAILABLE 917 929.200757113 192.168.100.101 → 192.168.100.110 Portmap 98 [RPC retransmission of #915]V2 GETPORT Call (Reply In 916) HCLNFSD(788585389) V:1 UDP 918 929.201092226 192.168.100.110 → 192.168.100.101 Portmap 70 [RPC duplicate of #916]V2 GETPORT Reply (Call In 915) PROGRAM_NOT_AVAILABLE 919 929.201744034 192.168.100.101 → 192.168.100.110 Portmap 98 [RPC retransmission of #915]V2 GETPORT Call (Reply In 916) PCNFSD(150001) V:2 UDP
The output from rpcinfo is:
$ rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 57318 status 100024 1 tcp 46225 status 100005 1 udp 53625 mountd 100005 1 tcp 40199 mountd 100005 2 udp 53980 mountd 100005 2 tcp 53443 mountd 100005 3 udp 50848 mountd 100005 3 tcp 49067 mountd 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 2 tcp 2049 100227 3 tcp 2049 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100227 2 udp 2049 100227 3 udp 2049 100021 1 udp 42943 nlockmgr 100021 3 udp 42943 nlockmgr 100021 4 udp 42943 nlockmgr 100021 1 tcp 44539 nlockmgr 100021 3 tcp 44539 nlockmgr 100021 4 tcp 44539 nlockmgr
Is the DOS based NFS client compatible with current day Linux NFS server? Any idea why I see messages saying PROGRAM_NOT_AVAILABLE? If something is supposedly missing, what program is it looking for? It would have been a lot more helpful if whatever program is reporting a "missing program" said what program it couldn't find, or couldn't talk to.
The DOS based NFS client was actually never compatible with NFS at all. People used to run pcnfsd on the server if they wanted a DOS client to connect. The call that is complaining is looking for an RPC service called HCLNFSD which was hummingbird's version of PCNFSD. Apparently Suse had a heavily patched version of some old unix pcnfsd code once upon a time that might work. I see someone mostly managed to get it to compile on gentoo 4 years ago. No idea if the hummingbird client would work with PCNFSD or really insists on only talking to the hummingbird server. Apparently the client came with source code for the server to run on your unix server (by which they meant AIX and similar of course, not that irrelevant toy named Linux). But basic answer is that DOS NFS clients were special and needed a server meant only for them, not a standards compliant NFS server. Or at least the authentication part was special. -- Len Sorensen
On 2022-06-28 21:50, Lennart Sorensen wrote:
The DOS based NFS client was actually never compatible with NFS at all.
That would explain why I'm having problems getting it to work.
People used to run pcnfsd on the server if they wanted a DOS client to connect. The call that is complaining is looking for an RPC service called HCLNFSD which was hummingbird's version of PCNFSD.
I did see references to HCLNFSD in the capture from tshark. Now they make more sense.
Suse had a heavily patched version of some old unix pcnfsd code once upon a time that might work. [snip] No idea if the hummingbird client would work with PCNFSD or really insists on only talking to the hummingbird server. Apparently the client came with source code for the server to run on your unix server (by which they meant AIX and similar of course, not that irrelevant toy named Linux).
I will see if I can find the source for the PCNFSD program. I'll see if the Hummingbird disks can be found that have the source meant for use with AIX. If I can find the sources I can take a shot at building it for Linux. I don't have access to the old DOS machine as it is located in another city which makes testing things more difficult.
But basic answer is that DOS NFS clients were special and needed a server meant only for them, not a standards compliant NFS server.
Thank you for the information, Lennart. I was hoping someone on this list might have some knowledge about this topic. I do have one other option I can pursue and that is to see whether a DOS based Samba client would work. I did a quick search and such a beast does exist but is not officially supported so my mileage will vary. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick
participants (3)
-
John Sellens -
Kevin Cozens -
Lennart Sorensen