Can't access shares

[Bbrraadd]

I'm having problems with users not being able to access shares on an NT4.0 server (SP6a). Sometimes they are able to access the share, sometimes they aren't. When they aren't, they get a message saying access is denied. They have adequate rights and permissions to the share. The server isn't out of licenses. Any thougths?

[Leif]

Do you have a maximum number of users limit set that might be being exceeded?

[Bbrraadd]

No.

[Bbrraadd]

I should probably also mention that I've deleted the share and recreated it. I still get the same response, sometimes users can access it, somtimes they can't.

[Leif]

Any pattern you can see as to when they can and can't? e.g. they can first thing after logging on, but not later in the day?

After having been denied access, are users later allowed access without any obvious action like a reboot?

[Bbrraadd]

No discernible pattern. Sometimes, they can log in and access the share immediately and then later be denied access. Other times, they can log in and be denied access but later they can access the share without any problems or a reboot in the mean time.

[Leif]

I'm afraid I'm reaching the limits of where I can help, but:

How are the users connecting? Through an application such as Word or Excel, or Explorer?

Are they mapped drives?

Are the users trying to access specific files, or just the folders?

[Bbrraadd]

They are accessing the share through both a membership type application and MS Office type apps. There is a drive mapping, however, the share can't be accessed through Network Neighborhood either. When they can't access the share, they don't have access to anything, shares, folders or files.

[jscher2000]

The inconsistency is indeed puzzling.

* Does a restart on the PC fix it?

* Can you tell if the problem is linked to the PC or to the username (i.e., by logging in as that user on a different PC, by logging in as administrator on the problem PC)? This could point to a problem with the PC retaining its "token."

* Are there any settings that could be expiring - DHCP leases perhaps?

* Have you ever used any third party tools to set permissions? I once trashed all my ACLs on a share using Security Explorer and had to rebuild all of the folders and move all of the files. I am more cautious now.

[Bbrraadd]

No, a reboot of the PC doesn't fix the problem. You'll remember that it is intermittent, sometimes they can connect, sometimes they can't. I've tried logging in to their PC with an Administrator login, same results. I've tried manually renewing the DHCP lease with winipcfg and still get the same results.

[mwolfman]

they have rights for the share, what about the folder itself??

[Bbrraadd]

Yes, they have rights for both. The problem is intermittent connectivity, sometimes they can access the share, sometimes they can't.

[jscher2000]

This would make me crazy.

* Is there anything in the server event log that provides any clues? I can't recall whether NT can or does log "access denied" requests.

* Tried swapping out the NIC card? Maybe it's getting flaky.

* PC trying to assert itself as master browser and getting shut down in some way?

* Bad tables in a switch or router?

* You could install a packet sniffer such as Iris on the PC and record the NetBIOS traffic to see if that shows anything unusual, but it's a ton of data.

[ibrown]

Yes, this can be a common problem when you have antivirus programs on your server. You can test this by removing the antivirus program and then try shares.

To fix the problem you need to edit the registry (all admins must master this ) The MS knowledge base articles advise how to fix it.

Check your event log for the message about "ipstacksize is too small..."

[DougJ]

This sounds like a user validation problem. Assuming you have multiple servers on the network, this is most likely caused by out-of-sync replication. If the security data's out of sync, a user could log in and get validated by ServerA, then get access to the share. But if the user gets validated by ServerB, which hasn't replicated with ServerA, the user is denied access to the share. This would explain the intermittent nature of the problem. It all depends on which server evaluates the user credentials.

How to troubleshoot? The best is to make sure all the rights are correct on the PDC, then make sure all your other servers are properly replicating with it. There's a couple ways to narrow narrow down which servers are causing the problem:
1. Set a DWORD registry key on the client HKLMNetworkLogonDomainLogonMessage=1
This will present a dialog box when the user logs in that shows which server did the validation.
2. Wait 'till you have a user that can't access a share, then check the Security log on each server to find out which one validated him/her.
3. As a drastic measure, disable the netlogon service on all but the PDC just to confirm that you're on the right track.

dcj2