thoffman
asked on
Cannot connect to network share - access denied to one server from a specific workstation and a specific user
This has been driving me nuts, mostly because it happens on my computer with my login. :)
Anyway, we have a network with a bunch of mixed workstations (mostly XP) and a handful of servers. We have a single domain with a bunch of mixed workstations.
1. Server A - The PDC running Server 2003.
2. Server B - The main file server, running Server 2003 R2.
3. Server C - The BDC, running Server 2003. This runs inside VMWare server on Server B.
4. Server D - NT4 server used for some legacy accounting software. This also runs in a VM on server B.
From my workstation (Windows XP), if I try to connect to any share on Server B, I get:
\\server\share is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
Access is denied.
Here are some scenarios that I've tried.
1. Login to my workstation as myself, connect using Start/Run/UNC Share - fail.
2. Login to my workstation as domain admin, connect using Start/Run/UNC share - success.
3. Login to my workstation as myself, map a drive - fail.
4. Login to my workstation as myself, map a drive as a different use, use my own name/password - success.
5. Login from another workstation as myself, connect using UNC - success.
6. Reboot my PC into Vista, login as myself, connect using UNC - success.
Of course, scenario 1 is the scenario I use most often. I'm using the mapped drive trick for now, but it doesn't seem to always work. I'm guessing that #4 is probably a big clue, but I can't figure out what this clue actually means.
In the process of trying to fix this, I fixed a few other (unrelated?) problems, such as:
1. BDC had been unable to sync with the PDC for awhile due to some DNS entries pointing to a third BDC that had been permanently removed.
2. My computer name and login name were identical. I noticed Vista would not let me do this, so I changed my computer name.
3. The computer browser service on the problem server was trying to load a backup list from itself. I never really fixed this, but edited the registry so the server wouldn't be a backup browser.
I also noticed that when I attempt to connect to a share from my workstation, the security log on server B shows the login succeeding from my user name. Then, it shows some logins from <ServerB>\administrator (not the domain admin), with my workstation listed in the details. Finally, it shows the login from my workstation (TH$) as succeeding.
Any ideas where to go next? I'm not against re-installing Windows on my workstation, but I'd rather keep that as a last resort.
--
Troy
Anyway, we have a network with a bunch of mixed workstations (mostly XP) and a handful of servers. We have a single domain with a bunch of mixed workstations.
1. Server A - The PDC running Server 2003.
2. Server B - The main file server, running Server 2003 R2.
3. Server C - The BDC, running Server 2003. This runs inside VMWare server on Server B.
4. Server D - NT4 server used for some legacy accounting software. This also runs in a VM on server B.
From my workstation (Windows XP), if I try to connect to any share on Server B, I get:
\\server\share is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
Access is denied.
Here are some scenarios that I've tried.
1. Login to my workstation as myself, connect using Start/Run/UNC Share - fail.
2. Login to my workstation as domain admin, connect using Start/Run/UNC share - success.
3. Login to my workstation as myself, map a drive - fail.
4. Login to my workstation as myself, map a drive as a different use, use my own name/password - success.
5. Login from another workstation as myself, connect using UNC - success.
6. Reboot my PC into Vista, login as myself, connect using UNC - success.
Of course, scenario 1 is the scenario I use most often. I'm using the mapped drive trick for now, but it doesn't seem to always work. I'm guessing that #4 is probably a big clue, but I can't figure out what this clue actually means.
In the process of trying to fix this, I fixed a few other (unrelated?) problems, such as:
1. BDC had been unable to sync with the PDC for awhile due to some DNS entries pointing to a third BDC that had been permanently removed.
2. My computer name and login name were identical. I noticed Vista would not let me do this, so I changed my computer name.
3. The computer browser service on the problem server was trying to load a backup list from itself. I never really fixed this, but edited the registry so the server wouldn't be a backup browser.
I also noticed that when I attempt to connect to a share from my workstation, the security log on server B shows the login succeeding from my user name. Then, it shows some logins from <ServerB>\administrator (not the domain admin), with my workstation listed in the details. Finally, it shows the login from my workstation (TH$) as succeeding.
Any ideas where to go next? I'm not against re-installing Windows on my workstation, but I'd rather keep that as a last resort.
--
Troy
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Verify that the system times are sync'd, at least as accurate as 5 minutes.
ASKER
saw380: The times match to the second; they both sync with the same time server.
Shift-3: I had tried clearing the NetBIOS cache. I even did a "repair" on the network connection. That didn't help. DNS is fine. WINS is disabled, since we use DNS exclusively (though I'm not sure why the last IT guy disabled it). NetBIOS over TCP/IP was disabled. I re-enabled it, and it didn't help, so I disabled it again. Suddenly, everything's working again. To be sure, I did a net use * /delete and rebooted. Sure enough, I can still browse to UNC shares on all the servers.
I'm not 100% sure if it was the enabling/re-enabling of NetBIOS over TCP/IP though. Right before I did that, I attempted to repair the network connection on the server. It reported that it failed to clear the ARP cache, so I didn't bother trying to connect. I'm starting to wonder if it actually did clear the ARP cache on the server, even though it reported that it failed. It's possible the ARP cache on the server was incorrect.
So, the fix wound up being either enabling/re-disabling NetBIOS over TCP/IP which caused Windows to rebuild something or clearing the ARP cache on the server. Your post definitely got me heading down the right road, so thank you.
By the way, if anybody's interested, the routing and remote access service can prevent a network repair from working. I temporarily stopped the service, and was able to complete the repair process.
--
Troy
Shift-3: I had tried clearing the NetBIOS cache. I even did a "repair" on the network connection. That didn't help. DNS is fine. WINS is disabled, since we use DNS exclusively (though I'm not sure why the last IT guy disabled it). NetBIOS over TCP/IP was disabled. I re-enabled it, and it didn't help, so I disabled it again. Suddenly, everything's working again. To be sure, I did a net use * /delete and rebooted. Sure enough, I can still browse to UNC shares on all the servers.
I'm not 100% sure if it was the enabling/re-enabling of NetBIOS over TCP/IP though. Right before I did that, I attempted to repair the network connection on the server. It reported that it failed to clear the ARP cache, so I didn't bother trying to connect. I'm starting to wonder if it actually did clear the ARP cache on the server, even though it reported that it failed. It's possible the ARP cache on the server was incorrect.
So, the fix wound up being either enabling/re-disabling NetBIOS over TCP/IP which caused Windows to rebuild something or clearing the ARP cache on the server. Your post definitely got me heading down the right road, so thank you.
By the way, if anybody's interested, the routing and remote access service can prevent a network repair from working. I temporarily stopped the service, and was able to complete the repair process.
--
Troy