Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Using Windows AD for security, I have three servers in a farm configured with the same share on all three. One one of the servers I cannot access the share it says my access is denied even though it is setup the same as the others.

I logged into another workstation and I am able to access the third server without issue.

What can I do/check on my workstation to see why I am being denied access to the server?

I have obviously rebooted and cleared all current connections and I am still having issues connecting. Is there a chance my workstation is being denied?

Thank you for any assistance,

Brett

edit: It's only from my main workstation I cannot access this one server of three. If I login to a different workstation I am able to access the share on the third server.

Tried IP address instead of machine name, same issue so not dns.

Don't know if this makes a difference, but I can map to the share, but receive an access denied when trying to use it. (only from my workstation)

I have explicitly given myself (domain\username) full control to the share and create rights on the folder and still cannot access the share.

Have tried to remove and recreate the share and am still receiving access denied.

EDIT:
Now this is an interesting finding (to me anyway) If I add the local group everyone to the share permissions I am able to access it. If I add myself or our domain everyone to the share permissions I receive an access denied. Remember this issue is only happening from one workstation to a one server. I setup a new share on the server and it acts the same exact way as the others.
Have I mentioned that I can access the scheduled tasks share?

share|improve this question

5 Answers 5

up vote 1 down vote accepted

Well I was able to resolve the issue, though I am not exactly sure why it was resolved.

I started by looking for the UNC name in the registry (\servername) and since I don't really need any of the entries there for applications (I only connect to upload files and terminal services) I started deleting keys containing the value.

After completing this and verifying they where gone I am able to access the share again!
Pretty wild if you ask me but I knew it had to do with the workstation and not server configuration.

The entry I found most strange was under key HCU/Software/Microsoft/Windows/CurrentVersion/Explorer/MountPoints2

Perhaps it was left over from all the testing I have been doing lately I am not sure, but a possible candidate.

To all who responded, I really appreciate your input. Thank you for your time

Brett

share|improve this answer

It might be a NTLM level requirement.

I've had this issue before. The server would accept the connection but fail when the creds were a lower then acceptable level.

share|improve this answer
    
Could you please enlighten me on how I would check this? –  Brettski Jun 26 '09 at 21:02
    

I'm not sure what you mean when you say a "farm", but I suspect it's a run-of-the-mill permission issue.

Access to a resource is based on the user account attempting the access, not the computer from which the access attempt is being made. I suspect that there's a difference in permission on the server that isn't acting the same as the other two.

If you would, use the "CACLS" command to dump the NTFS permissions on each of the server computers and post them here (sanitized as necessary). If the "C:\Foo" folder is shared, I'd be looking for the output of the command:

CACLS C:\FOO

You can redirect the output of that command to a text-file with the syntax:

CACLS C:\FOO > filename.txt

The "share permissions" are also suspect, but there's no good way to dump those to a text file to post here. In "Computer Management" on each server, nagivate to "System Tools", "Shared Folders", and "Shares". Display the "Properties" for the shared folder in question, go to the "Share Permissions" tab, and examine the permissions.

share|improve this answer
    
most of the time it's forgetting that Share Permissions are not the same as Access permissions. –  Knox Jun 25 '09 at 22:53
    
Yep. I wish Microsoft would just kill that unnecessary "feature". No one has needed "Share Permissions" for years. Nobody shares folders on FAT volumes anymore. The canonical permission live on the NTFS, period. sigh –  Evan Anderson Jun 25 '09 at 22:55
    
I really don't think its an issue on the server. Remember I stated that I am able to access the share if I login to a different workstation and access the share. It's only from my main workstation I cannot access this one server of three. –  Brettski Jun 26 '09 at 16:13
    
Yes Evan, farm is irrelevant. I said it more as the three machines are configured the same as they are load balanced application servers. Thank you for your response. –  Brettski Jun 26 '09 at 16:15
    
There's no mechanism in the Windows permission system to deny access based on the computer being used to access a resource-- only the user context. Something else is in play. Your name resolution from the "main workstation" to the problem server computer is good, right? You're not seeing anything in the security event log on the problem server computer? –  Evan Anderson Jun 26 '09 at 17:03

Get Account Lockout Tools from Microsoft. LockoutStatus, will tell you if a user is locked out, and every DC in your domain. If you are having AD replication errors, one controller may have you locked out.

share|improve this answer
    
I am not locked out as I may access the share as me from a different workstation. –  Brettski Jun 26 '09 at 16:26

What OS? Might be a firewall issue on that one server.

Check the permissions on the drive that the share is located. Might have some inheriting permissions.

share|improve this answer

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.