Network permission denied on one of three servers from one workstation

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.