Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
I would recommend asking for a moderator to move your question to ServerFault.com as this kind of issue is exactly in SF's wheelhouse –  Scott Chamberlain Feb 29 '12 at 18:58
add comment

7 Answers

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
share|improve this answer
    
I checked and this this setting was already set this way. –  Nick Feb 2 '12 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 '12 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 '12 at 18:05
add comment

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?

share|improve this answer
    
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 '12 at 16:34
add comment

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

share|improve this answer
    
Can you elaborate as to why this would make a difference? –  soandos Oct 21 '12 at 1:06
    
I can't be thankful enough for how this answer solved MY problem! –  MarcH Feb 6 '13 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 '13 at 13:52
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.