Share via

Sco (Unixware cannot access NFS share from windows 2008)

  • Article

Recently we got multiple issues, where Unixware client was unable to access NFS share on a Windows 2008 machine. UnixWare client seems broken - it sends V4 GETADDRLIST call and when the server replies, it cannot understand the reply and fails to list or mount the shares. Deleting the registration using rpcinfo -d syntax doesn't seem to help. The same Unixware client works fine when mounting a share from a Windows Server 2003 NFS server on the same network.

We collected Network traces to get to the root cause of the issue.

Analysis from the network trace while running the rpcinfo –p command from clients against the server:

Client invokes “rpcinfo –p < Server IP/hostname>”

                Client issue PMAP_DUMP dump request (portmap v2)

                Portmap replies with PMAP_DUMP reply

 

On some of the Unix flavors we may also get the error message while running showmount command against the NFS share. For example: “showmount –e <server IP/hostname>”

                Client issues RPCBIND_GETADDRLIST for tcp, <Server IP>, port 111

                Portmap replies with a list of 4 entries including tcp, udp, tcp6 and udp6

 

Client issues RPCBIND_GETADDR using udp for udp, <server IP>, port 111, program 100005 (MOUNT)

Portmap replies with single entry for 0.0.0.0.4.24 i.e. port 1048

 

This is where the UnixWare issue is. The UnixWare client issue the RPBBIND_GETADDR using the same Xid as it used for the RPCBIND_GETADDRLIST call. It should not do this. Xids should not be re-used anywhere near this quickly. Fortunately, portmap replies with a response suitable to the request rather than just replaying the reply it gave for Xid .

 

Same happens with mount command:

Client invokes “mount <server Ip/ hostname>:/tmp /mnt/tmp”

 Client issues RPCBIND_GETADDR using udp for udp, <server IP>, port 111, program 100005 (MOUNT)

Portmap replies with single entry for 0.0.0.0.4.24 i.e. port 1048

Client retries request 7 times and each time portmap replies with the same answer as before.

 

We see nothing that indicates portmap is having any trouble with responding to the GETADDR calls.

This only happens with the earlier Unix flavors like SCO, Unixware however other Unix / Linux flavors work like AIX, HP-UX, Solaris, Linux works fine.