13

One of the lab computers at the school I administer is not able to access a any shares under the \\ad\data$ directory. I can access it from any other computer on the network. If I use the IP \\192.168.1.248\data$ I can access the files properly. If I use the FQDN: \\ad.domain.name\data$ it also works. Any other computer at the school is also able to access this share properly.

When I try to access the share with \\ad\data$ I get the message "You do not have permission to access \\ad\data$. Contact your administrator to request access." I am logged in with the domain administrator account.

Any idea on what would cause a single domain computer to not be able to access a share that it should have access to?

The server is running Windows Server 2008 and the computer is running Windows 7 SP1.

UPDATE

Issue is now happening on multiple other computers on the network, staff computers and student computers. I am starting to think there is something seriously wrong with the Active Directory server.

Improve this question
1

11 Answers 11

Reset to default
5

Win7/server 2008 > control panel type in "Credential manager" and delete any saved credentials.

Improve this answer
4
  • Can you elaborate as to why this would make a difference?
    – soandos
    Oct 21, 2012 at 1:06
  • I can't be thankful enough for how this answer solved MY problem!
    – MarcH
    Feb 6, 2013 at 17:35
  • Tried it and it didn't work for me. It could make a difference because of incorrect/expired credentials (for example if you changed the password).
    – surfen
    May 5, 2013 at 13:52
  • This worked for me, although not 100% sure why. Once I connected using the hostname, I could still go back and use the IP address even!
    – Adam Nofsinger
    Dec 17, 2020 at 20:20
4

I have just had a similiar problem.

We have a domain and AD, and all users home folders are set up in the AD.

The user works on a terminal server and her home folder works fine On the new notebook we were setting up for her, the drive was mapped, but if you tried to access it via unc or by double clicking on the mapped drive it gave an error of the location could not be found.

Browsing through a few other forums I noticed someone asked if the home folder could be access via IP or FQDN. When I tried that I could access the folder.

At first I also thought it was a DNS problem.

Reading further on someone said " try deleted the CSC cache", and then I almost swore at myself. Knowing that this notebook was used by another user that made use of offline files (Also their home folder on the same server). I found a quick way to delete the CSC cache on Win 7 (its a lot easier on XP). Rebooted the computer and the problem was solved.

Here are the links I found the info on:

http://www.petri.co.il/forums/showthread.php?t=60629

http://support.microsoft.com/kb/942974

Improve this answer
1
3

I have seen an issue like this and it was caused by the DNS being set not to append the domain name automatically.

So, I would check that Append primary and connection specific DNS suffixes is selected and that Append parent suffixes of the primary DNS suffix is ticked.

This can be found via

Control Panel\Network and Internet\Network and Sharing Center
Local Area Connection Status
Properties
Internet Protocol Version 4 (TCP/IPv4) and/or Internet Protocol Version 6 (TCP/IPv6) 
Properties
Advanced
DNS
Improve this answer
3
  • I checked and this this setting was already set this way.
    – Nick
    Feb 2, 2012 at 16:28
  • If you open up a command prompt and type nslookup ad does it give different results from what you get if you type nslookup ad.domain.name ?
    – sgmoore
    Feb 2, 2012 at 17:59
  • The results are the same and when I do nslookup ad it shows me the ad.domain.name along with the correct address
    – Nick
    Feb 2, 2012 at 18:05
2

I had the same problem (happened to me several times) and I resolved it by deleting all connected shares and recreating them. There have been multiple connections to same locations (using different URLs) and I suspect that it was the reason of problems.

Using command line:

  1. To see currently connected shares
    net use
  2. To delete connection to share Y on xxx.xxx.xxx.xxx
    net use \\xxx.xxx.xxx.xxx\Y /delete
  3. To delete connection to share Y on XXX
    net use \\XXX\Y /delete
  4. To delete mapped network drive
    net use Y: /delete
  5. To reconnect mapped network drive
    net use Y: \\xxx.xxx.xxx.xxx\Y /PERSISTENT:YES /USER:XXX\user /SAVECRED

Another potential suspect is Samsung PC Share manager. After uninstalling it from the host the problem disappeared.

Improve this answer
0
1

It could be possible that the client computer is using saved credentials. You can check using the Windows Credential Manager under Control panel.

Does this occur under a Local Admin account, eg machine_name\Administrator?

Is the machine authenticating to the domain controller properly?

Improve this answer
1
  • There are no saved credentials on the client computer. The local admin account has the same issues as the domain accounts. The machine is logging into the domain fine, it is applying group policies as expected.
    – Nick
    Feb 2, 2012 at 16:34
0

Make sure that you aren't already connecting to \ad using different (or old) credentials. I've seen similar issues when I had a mapped drive connected to a share on a server using my "regular" domain account and then I tried to connect to another share on the same server using my domain "admin" account.

Does a reboot resolve the problem?

Improve this answer
0

I've had a related problem. I've had an XP Home machine accessing shares/shared folders and drives on a Windows 7 machine. I was playing around with the Workgroup / Homegroup settings on Windows 7 and changed the "Password protected sharing" option. I could see my shared folders on my XP Home machine, but could not read or write from/to them. It was driving me mad - because when I created a new user on the XP Home machine, and accessed my shares on the Win 7 machine, there were no problems - I could read and write files!

So I went back to my old (main) user account and I could still not access the shared files...

I tried all kinds of solutions - net use * /del and I tried deleting user accounts net user /delete - I tried to get rid of cached credentials - but nothing worked. Accessing the shares via an IP address DID work! Argggh!!

I tried setting the Workgroup on both machines to Workgroup (XP HOME machine was MSHOME)

Eventually what I had to do was change the COMPUTER NAME on my Windows 7 machine, rebooted, then accessed my shared folders from the XP HOME machine. It then asked me for a Logon user/password which I re-entered. However, I had paths and stuff which used my old computer name, so I then changed my Win 7 computer back to what it was originally. Alleluia! It worked - again I was asked for user/password and I could access my shares from XP HOME machine!

So, summary: there is some problem with cached credentials and no obvious way to delete them (nothing was shown in Network Password manager in the user account either). Therefore, Change your computer name temporarily and change it back and that could fix some issues.

I came across several similar issues on forums like these, but none the same as mine.

Improve this answer
0

I had this issue after upgrading a Server 2008 R2 box to Server 2012 R2 with update. For me going into Credentials Manager and removing Windows Credentials -> Generic Credentials resolved the issue.

Improve this answer
0

In one of my cases, to my surprise, it just turned out to be that I needed to flush the DNS cache in addition to enabling the SMB 1.0 support feature in Windows 8.1. This was a domain-joined computer that was disconnected from its domain.

In the other case, a non-domain-joined computer, flushing the DNS cache didn't help. However, curiously, the fully-qualified name \\Name. worked when \\Name didn't (I didn't try this son the first machine). I'm not sure what the problem here is, but I'm guessing it's related to the lack of a domain name.

Improve this answer
1
  • Worth noting for anyone stumbling by, please DO NOT ENABLE SMB 1.0 for any reason! Due to the exploit EternalBlue, SMB 1.0 is extremely insecure.
    – duct_tape_coder
    May 21, 2020 at 0:09
0

We experienced this occurring on one specific folder only. Turns out Offline Folders caused the issue because we use redirected folders. So Windows is literally connecting to that share with the other users credentials as soon as Windows starts so it refuses the connection from the logged in user.

The solution used was to turn off offline sync.

Improve this answer
0

Could be network ACLs. In one environment I worked in they were changed to block port 445. So:

\hostname\share

  • Client tried to connect via SMB on TCP/IP port 445
  • Blocked by network ACLs
  • Client fails to connect

\hostname.fqdn\share

  • Client tried to connect via SMB on TCP.IP port 445
  • Blocked by network ACLs
  • Client connects via NetBT on port 139
  • Successful connect

So just so happened that connecting to FQDN tries to use NetBT, and port 139 was open, so was successful.

So solution was unblocking port 445.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .