Windows – Connection from application on network share fails

mappeddrivenetwork-sharenetworkingwindows

EDIT:
I tested some more…If I copy nslookup from the Windows directory to my mapped network drive, it cant' resolve hostnames:

H:\nslookup dbserver
(null)   UnKnown
Address:  192.168.0.195

If I use the default nslookup from C::

C:\>nslookup dbserver

Server:  dnsserver.dom.local
Address:  192.168.0.195

Name:    dbserver.dom.local
Address:  192.168.0.231

So it doesn't have anything to do with oracle, I'll change title and tags.


My colleagues create applications which use the installed Oracle-client to connect to remote Oracle-DBs. Running these applications from a mapped drive on DFS (on two servers) results in a successful connection. Running them from a mapped drive on another server (standalone fileserver) results in NO connection whatsoever. I traced it via Wireshark and observed that there is not even a try to establish a connection (no oracle-packets at all are exiting the client).

I disabled firewalls on the DB server, the filserver and the clients, but to no avail. All the mapped network drives (DFS and standard fileserver) have been put into the intranet zone.

If I use tnsping from my local Oracle-client installation, I can resolve the host:

OK (20 ms)

If i use tnsping placed into the mapped network drive on the fileserver, I cant:

TNS-12545: Connect failed because target host or object does not exist

To the SAME Oracle-DB.

I am at a loss here, see the failed attempt log excerpt below:

nfun2awanm: Getting the path of sqlnet.ora
nnfun2awanm: Getting the adapter name
nnfun2awanm: exit
nsmal: 216 bytes at 0x75e228
nscall: connecting...
snlinGetAddrInfo: entry
snlinGetAddrInfo: getaddrinfo() failed with error 11003
snlinGetAddrInfo: exit
nlad_expand_hst: GetAddrInfo call failed
nladini: entry
nladini: exit
nladget: entry
nladget: exit
nsmal: 89 bytes at 0x7b2c48
nsc2addr: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dbserver)(PORT=1521))(CONNECT_DATA=(SID=instance)))
nttbnd2addr: entry
snlinGetAddrInfo: entry
snlinGetAddrInfo: getaddrinfo() failed with error 11001
snlinGetAddrInfo: exit
nttbnd2addr: looking up IP addr for host: dbserver
snlinGetAddrInfo: entry
snlinGetAddrInfo: getaddrinfo() failed with error 11003
snlinGetAddrInfo: exit
nttbnd2addr:  *** hostname lookup failure! ***
nttbnd2addr: exit
nserror: nsres: id=0, op=77, ns=12545, ns2=12560; nt[0]=515, nt[1]=1003, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
nsmfr: 89 bytes at 0x7b2c48
nscall: connecting...
nladget: entry
nladget: exit

In comparison to the succesful tnsping:

nnfun2awanm: Getting the path of sqlnet.ora
nnfun2awanm: Getting the adapter name
nnfun2awanm: exit
nsmal: 216 bytes at 0x31426e8
nscall: connecting...
snlinGetAddrInfo: entry
snlinGetAddrInfo: exit
snlinGetNameInfo: entry
snlinGetNameInfo: exit
snlinFreeAddrInfo: entry
snlinFreeAddrInfo: exit
nladini: entry
nladini: exit
nladget: entry
nladget: exit
nsmal: 95 bytes at 0x30f3158
nsc2addr: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.231)(PORT=1521))(CONNECT_DATA=(SID=instance)))
nttbnd2addr: entry
snlinGetAddrInfo: entry
snlinGetAddrInfo: exit
nttbnd2addr: using host IP address: 192.168.0.231
snlinFreeAddrInfo: entry
snlinFreeAddrInfo: exit
nttbnd2addr: exit
nsmal: 996 bytes at 0x3142bc8
nsmal: 2120 bytes at 0x3142fb8
nsmal: 84 bytes at 0x3143948
nsopen: opening transport...
nttcon: entry
nttcon: toc = 1
nttcnp: entry
nttcnp: exit
nttcni: entry
nttcni: Tcp conn timeout = 60000 (ms)
nttctl: entry
nttctl: Setting connection into non-blocking mode
nttcni: trying to connect to socket 564.
ntt2err: entry
ntt2err: exit
ntctst: size of NTTEST list is 1 - not calling poll
nttctl: entry
nttctl: Clearing non-blocking mode
snlinGetNameInfo: entry
snlinGetNameInfo: exit
nttcni: connected on ipaddr 192.168.0.99
nttcni: exit
nttcon: set TCP_NODELAY on 564
nttcon: exit
nsopen: transport is open

By pasting these results into serverfault, I just realized that the successful attempt can resolve the hostname via DNS, the failed one can't. So it seems it's not even Oracle-related?

Best Answer

It's a hostname resolution issue, as you suppose, on the standalone server.

The TNS alias on the standalone server, where the name dbserver is used, seems different from the one on the servers where the tnsping is working, where the IP 192.168.0.231 is used.

You can modify the tnsnames.ora file on the standalone server to use the IP 192.168.0.231 or add an entry to the hosts file to resolve the name dbserver