Troubleshooting Unwanted 'Access Denied' Messages in Workgroup-Based Networks

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : October 1, 1997

By Shane Creamer with contributions by Kip Gumenberg

Abstract

This white paper applies to Windows 95, Windows NT 3.x and 4.0, Windows for Workgroups 3.11, MS Network Client for MS-DOS installed in workgroup-based networks and is the first in a series of white papers on this topic. The next white paper will discuss troubleshooting unwanted "Access Denied" messages in Domain-based networks and is due to release on TechNet during the first quarter of 1998.

The intent of this white paper is to help users at the basic to intermediate knowledge-levels identify and resolve the most common problems indicated by unwanted messages that state something similar to "Access has been denied" (hereafter referred to as "an Access Denied message") or perhaps only partial access such as "You have only Read Access; changes will not be saved." Although this white paper is not meant to be an all-encompassing solution, it does give a good foundation to help you isolate problems.

After defining some common terms, this white paper proceeds with discussing the troubleshooting of unwanted "Access Denied" messages on computers that access resources in a workgroup environment where each computer has its own user accounts and passwords database. This white paper, however, does not cover troubleshooting "Access Denied" messages in Domain-based networks which will be the subject of the next white paper mentioned above. Domain-based networks deal with computers that access resources in a Windows NT Server domain environment where trust relationships, replication, and other domain-specific issues can cause "Access Denied" messages.

Definitions

Workgroup

With workgroup networking, users and resources that are shared out are unique to that specific computer and are not common to other computers. The administrator of a particular computer must maintain users, shares, and permissions, instead of having a centralized location where users and resources are kept and maintained (such as a Windows NT Server domain). Clients in this environment typically run Windows for Workgroups 3.11, Windows 95, or Windows NT Workstation. The server typically runs Windows NT Server.

Windows NT Server domain

With a Windows NT Server domain, you can maintain machine and user accounts in a centralized location for easier administration and configuration. User and password information is maintained on the domain controller of the Windows NT Server domain.

Client

The client is the computer from which a user tries to connect to a remote resource. This can be an MS Network Client for MS-DOS, a LAN Manager client, or a computer running Windows 3.1, Windows for Workgroups 3.11, Windows 95, or Windows NT Workstation.

Server or Host

The server or host is the computer that has the resource that the user tries to connect to. Note that before a computer can function as a server for clients to connect to, that computer must have a server component or service. Computers running Windows NT Workstation or Windows NT Server have the server service installed by default, but if you have a computer running Windows 95, you must manually add "File and Printer Sharing for Microsoft Networks" service in Control Panel Network.

Resource

A resource is something (for example, a printer, fax machine, CD-ROM drive, or a directory) on a remote computer that a user attempts to connect to. A resource may also be called a "share" because it can be shared out for clients to connect to.

Workgroup Networking

Sharing files on Computers Running Windows 95

If you receive an Access Denied message or similar message in a workgroup network, go to the computer that has the share you are attempting to connect to and examine the permissions on the share. Check to see if the share has permissions set to Read-Only or Full control. Also check to see if a password is required to access the share. This would be the case if the administrator of the share of a computer running Windows 95 specified a password in the Read-Only Password or Full Access Password fields of the share's property dialog box. The following picture shows an example:

Cc749911.acdenid1(en-us,TechNet.10).gif

Figure 1: . Drive C Properties Dialog Box

Sharing Files on Computers in a Windows NT Workgroup

Computers running Windows NT have two capabilities in a workgroup that client computers running Windows 3.1, Windows for Workgroups 3.11, or Windows 95 do not. Computers running Windows NT have the ability to specify specific users' access to a resource, as well as the ability to specify users on the local file system. Note that Figure 1 above is taken from a computer running Windows 95 configured for workgroup networking and there is no field to specify users. (Windows 95 clients configured for user-level security will be discussed in the Domain-based networks white paper.) Figure 2 below shows the ability of Windows NT to specify local users, rather than just Read-Only, Full, or Depends on Password permissions that are shown in Figure 1.

Cc749911.acdenid2(en-us,TechNet.10).gif

Figure 2: . Windows NT 4.0 Add Users and Groups Dialog Box

File Permissions (Windows NT NTFS-Partitions Only) and Share Permissions

The next picture below shows permissions on a computer running Windows NT.

Note that the Directory Permissions dialog box implies that the computer has an NTFS partition, which gives it the ability to have its own permissions underneath the share-permission level. If this was a FAT file system partition, this dialog box would not be available. But note that Everyone/Full Control is the file level permission, and that there is neither a user nor a group specified with No Access. Therefore, a fictitious user "Bob" would have all the necessary permissions from the file system to read and write files from and to that share.

Cc749911.acdenid3(en-us,TechNet.10).gif

Figure 3: . Windows NT 4.0 Directory Permissions Dialog Box

When a user attempts to connect to a remote resource that is on a Windows NT computer, and the share is located on an NTFS file system, Windows NT always uses the most restrictive of the share and file permissions to apply to that user.

For example, assume a share called "Documents" is created on a computer running Windows NT, and a user named Bob is attempting to copy a file to this share, load (read) a file from that share into a Word processor and then save it to the same name after he made changes to it.

  • If the Documents share has Bob/Read-Only permissions and file permissions are Bob/No Access, then Bob's cumulative permissions are Bob/No Access, so Bob will get an "Access Denied" message when he attempts to copy the file to the share or when he tries to access any files on that share.

  • If the Documents share has Bob/Read-Only permissions and file permissions are Bob/Full Control then Bob's permissions resolve to Bob/Read-Only, so Bob will get an "Access Denied" message when he attempts to copy the file to the share but can read and open files from that share. However, he will get an "Access Denied" message when he attempts to write changes to an exiting under its current or a new name (same as copying a file to the share) on that share.

  • If the Documents share has Bob/Full Control permissions and file permissions are Bob/Read-Only, then Bob's resulting permissions are Bob/Read-Only for the existing files on that share, so Bob can copy the file to the share, can read and open the Read-Only marked files from that share, but will get an "Access Denied" message when he attempts to write changes to those Read-Only files.

  • If the Documents share has Bob/Full Control permissions and the file permissions are Bob/Full Control then Bob's permissions are Bob/Full Control, and Bob can copy the file to the share and read, open, and write to all files on that share.

Troubleshooting Unwanted "Access Denied" Messages

The following are some things you can try to resolve these types of messages:

  • Check the share permissions to see if "Everyone" is specified, or if only a particular user is specified

  • Check to see if you can connect to the share if you enable the local Guest account on the computer with the share.

  • If both computers have the same user account, try resetting the passwords on both computers.

  • In Windows NT Explorer, right-click on the file or directory you want to access, click Properties, click the Security tab, and click Permissions to verify that there is no restriction on the NTFS file system that would keep the clients from connecting at all, or that gives the clients less permissions than you want them to have. Windows NT applies the most restrictive permission to the client when going from the share permission to the file permissions.

  • Check to see if the user is specifically given permissions, or if permissions are assigned to groups.

  • Check to make sure that the user actually belongs to the groups that have the proper permissions.

  • Check to see if the Share or File System specifies a No Access permission to a group or user.

  • Check to see if the resource in the same domain as the user or if it is on the network in a domain that has a trust relationship. Check to see if you can connect to the resource with a different user account.

  • Check to see if someone with Administrator level privileges to that resource can connect to it.

Access Denied Messages from within Applications

If a message appears stating that access was denied to your client while you are running an application (such as when you attempt to open a file in Microsoft Word from a shared directory), you can try using another application to see if the same problem occurs to rule out that the application has a problem which would be indicated if you can successfully open a file from the other application. If you don't have another application, you can also check if you can access the share (with the file you want to open) from a command prompt and attempt to copy a file to your local drive as a test. If the copy works, the problem appears to be specifically related to that particular application. At this point, it would be best to contact your systems administrator for a resolution to the problem.

If you are working with a file in an application and you are trying to save a file to the same name you opened it with and you get an Access Denied message, try saving the file to a different name. If that works, the original file has a Read-Only attribute assigned to it. If it does not work, however, you may not have write access to that share.

Additional Information:

For additional information, see the following articles in the Microsoft Knowledge Base at https://www.microsoft.com and click on the Support tab:

124860 Real Mode Redir Domain Validation Err Msg: Access Denied

135060 Access Denied Attempting to Change Client Domain Password

116043 Network Share Access Denied After Limit Met, Then a Disconnect

119491 File Manager Displays Deleted Partitions