When a member of an Active Directory domain is unable to connect to a shared folder on the network, there are a number of possible causes. This article discusses the most common ones and provides information that should help to resolve the issue.
The first step in addressing the issue should be to determine its extent. If only one machine or user account is unable to access a share, there is more likely to be a problem with that specific machine or user account rather than the server hosting the share.
It is also important to determine, as accurately as possible, when the issue began and whether any changes were made around that time. An issue that appears immediately after configuration changes are made is likely a result of those changes, but one that appears "out of the blue" may be caused by a malfunction of some sort.
Below are some common causes of share-access issues and suggestions for resolving them. For brevity, file server refers to the server on which the share is hosted, and client refers to the machine attempting to access the share.
If the issue affects many or all machines in the domain, verify that the network adapters on the file server have up-to-date drivers and firmware. New driver and firmware versions are often released to correct issues in previous versions, and these releases sometimes happen frequently.
Occasionally, a new driver or firmware release will cause an unexpected issue that wasn't present in a previous version. If the file server's drivers and firmware are already up to date, reverting to a previous version may resolve the issue.
Be aware that network adapter driver and firmware changes shouldn't typically be performed on a production server during business hours, as they will cause the server to be offline for a short time.
If a single machine has trouble accessing a share, the DNS settings on that client may be incorrect. A simple way to test DNS is to attempt to access a share using the file server's IP address rather than its name (for example, attempt to connect to \\192.168.1.10\share rather than \\fileserver\share). If you are able to successfully access the share using the server's IP address, DNS is likely to blame for the issue. If DNS is indeed responsible, you will receive an error similar to the following on the client when you attempt to access the share, though it may take a few minutes for the error to appear:
The ipconfig /all command can be used to verify that the client is using the correct servers for DNS:
All domain-joined machines should use only DNS servers that are internal to the domain. Using other DNS servers will result in intermittent name-resolution failures, which in turn can cause problems accessing shared folders.
If multiple machines cannot access shares on a server, it is possible that the file server is not registered correctly in DNS. This may be due to incorrect DNS servers being used by the file server. Run the ipconfig /all command on the server and verify that it is using the correct DNS servers. If they are correct, open the DNS console on at least one of the domain's DNS servers and verify that the file server's registered host record is present and contains the server's correct IP address.
If there is a firewall or intrusion-detection/prevention software (IDS/IPS) running on the file server, it may be blocking attempts to access the share. If this is the case, all machines on the network will typically be blocked from accessing the share unless very specific firewall rules are in place.
The quickest way to verify whether a firewall/IDS/IPS is causing the problem is to disable it temporarily, if company security policies allow this. To disable the Windows Firewall, see How to Properly Turn Off the Windows Firewall in Windows Server 2008 and Above. To disable third-party software, refer to its accompanying documentation. Note that some third-party security software includes filter drivers which are not disabled when the application is disabled. If this situation, uninstalling the software is the only way to disable the filter drivers.
If security policies do not allow the firewall/IDS/IPS to be disabled, check any logs generated by the software. They should list any access attempts that have been blocked.
Disabling or uninstalling the software is not a long-term solution in most cases due to security considerations. Instead, the software will need to be properly configured (the appropriate rules will need to be created, in other words) to allow users to access shares on the server while keeping unwanted traffic out.
It is possible that permissions on the shared folder do not allow the currently logged-in user to access it. There are two sets of permissions that come into play when accessing a shared folder across a network: share permissions and NTFS permissions. These are discussed further in Understanding File and Folder Permissions in Windows. Both of these sets of permissions must allow access in order for a user to be able to read or modify the data in a shared folder.
If permissions are preventing access to a share, you will receive an error similar to the one below when trying to access it:
To test whether permissions are restricting access to a share, log into a different user account (one with administrative-level access, if possible) and try to access the share again. To completely rule out permissions as the cause of the issue, set the share and NTFS permissions to Everyone - Full Control and try to access the share again. This constitutes a security risk, though; the permissions shouldn't be left in this state for longer than it takes to test access.
|Need more help?|
|Find additional PowerEdge and PowerVault articles|
Visit and ask for support in our Communities
Create an online support Request
Identificación del artículo: SLN156704
Última fecha de modificación: 01/11/2017 04:06 AM