Quote:
Originally Posted by
ThePistonDoctor
I can map a network drive to \\aixservername\nfssharename and it sees it, but I get "Access is denied" when I try to open it.
I assume this is because it's not recognizing the domain username on the Unix side[...]
A few clarifications first:
NFS (network file system) is a protocol and is part of the TCP/IP protocol suite. Classically it used UDP to transport its information and worked on top of it, modern versions (NFS4) use TCP in the transport layer.
Windows is NOT (really!) using TCP/IP at all. Windows is using a protocol suite called NetBIOS and this protocol suite includes a protocol which serves a similar purpose to NFS: the SMB (server message block). Microsoft has, in the wake of the Internet, claimed that Windows today utilizes TCP/IP, but this is a half-lie: what Windows does is to use TCP/IP as a mere transport protocol to transmit normal NetBIOS protocol frames. All the Windows network functions (like Directory management, file sharing, etc.) are all still built on NetBIOS facilities which just get transmitted enclosed in TCP frames instead of being transmitted natively (like in Token-Ring frames).
The principal problem you face is that both Unix and Windows are using TCP/IP to transmit information, but while Unix uses a real TCP/IP protocol suite (telnet/ssh for remote login, nfs for file sharing, lpr/lpd for print services, etc.), Windows uses TCP only to tunnel another network protocol suite.
One possibility to overcome this is to implement (parts of) the NetBIOS protocol suite in Unix. This is what Samba and similar products do. Samba is the implementation of the SMB (hence the name) protocol as a Unix daemon. Install it on the Unix system and you could export parts of the local file system as "network shares", which represent the SMB pendant to an NFS export. You could even connect this "SMB server" to a domain and handle the user/rights administration from your domain controller.
Another possibility is to implement a full-featured TCP/IP-protocol stack in Windows. This is what - however clumsily - "Unix services for Windows" does.
So, after this rather long-winded explanation, what can you do to remedy your problem. Lets assume the problem is on the Windows side:
- NFS relies on the RPC (remote procedure call) protocol. Make sure that your Windows system is able to answer RPC calls from the remote server.
- It might be that the NFS server uses an older NFS protocol. Make sure that both server and client use the same transport protocol (TCP or UDP). UDP even might be better in settings with packet sizes which are large relative to NFS's data transfer size (i.e. Ethernet Jumbo Frames are enabled).
- NFS servers run either portmapper or rpc.bind daemons to advertise service endpoints to their clients. This can cause problems with firewalls between server and client. NFS often uses port 2049 but auxiliary services (i.e. NLM) use random ports and the rpcbind uses 111.
- Usually NFS shares are exported to hosts, not user/host combinations, so i suppose your point with the Unix UID is mute. However, you will need to "mount" the filesystem once you see it exported to your system.
- In AIX the command "showmount -e <hostname>" will show you all the exported directories of the host <hostname>. I have no idea if this command is available in WIndows when the Unix Services for Windows are installed. If it is use it to find out if the directory is indeed exported and available for you.
I hope this helps. If you suppose that the problem is with the Unix system state that here, get root access to the system (NFS configuration needs root privileges) and report back to here.
bakunin