Can map drive but not browse XP Pro SP3 shares unless setup as PowerUser or Admin on shared machine

start, run, secpol.msc

Check Local Policies\User Rights Assignment
"Access this computer from the Network" and
"Deny access to this computer from the Network"

Also, make sure simple file sharing is turned off and double check both share and NTFS permissons.

http://support.microsoft.com/kb/307874

Also, when you pull up the system via unc are you using the computer name or IP address?

If you right-click on the share, left-click properties, and click on the Permissions button, what permissions are set for Users?

To answer ya'lls additional questions:
1.) Access this computer from network = explict usernames (the ones having trouble with); no groups or
 everyone (by design)
2.) Deny access to network = guest (only one)
3.) Does not matter if I use \\ip-address or \\computer-name (same result - is not accessible. You might not have permission to use this network resource)
4.) Simple file sharing is off
5.) Permissions on NTFS are standard (all users) and verified.  Only share permissions, I set them different per user (explicitly, not group) as needed.  They work as should (R/W/none) when mapping drive.
6.) Do have all users set to not be able to log on locally to file share (tested w/ and w/o - same result).

It acts consistent ... Only admins or powerusers (on file share) can view share listings (browse computer)

I'm a little stumped ATM.  Are there any applications installed on the XP server or client for that matter that do anything with networking like Firewall, Antivirus, Antispyware, Proxy, Secure Browsing, or anything like that?

Only windows firewall (disabled) and Avast AV (tried it disabled).  Since it works so consistently with mapped drives and those with admin or poweruser accounts have no problem browsing ... it has to be a registry setting or sec pol setting embedded somewhere.

1)  Login names and passwords must be identical at both ends of the share meaning the user has the same password to login to their PC as their username has on the "server". (Tip: You can make them disappear from the welcome screen on the "server" with TweakUI)
2)  All users belong to groups (Member of) tab in their properties.
3)  The best practice is to control the access to the share by their group membership rather than their username and excessive granularity in permissions always causes problems.  If you replace a PC, never reuse the same username!  That username is tied to a GUIID which was randomly generated and will never match an older one.
4)  The use of Limited or Standard accounts stopped being an effective method of preventing infections over two years ago.  The malware launches itself as the SYSTEM account which supercedes the Administrator's authority.

Make everyone a member of the Users group at both ends of the connection(s) and give it the minimum permission level to the share.  Then, add the users that need higher permissions either explicitely or through the use of the Power Users or Administrators groups.

To repond to Davis McCarn:
1.) Login names and passwords are same on both ends - checked and proven since permissions work fine with net use mapping
2.) All users belong to "users" group on file share.  Must make them members of "power users" or admin" to be able to see browse shares on file share --- this is the issue
3.) There are only 4 users at this point.  Groups will work fine.
4.) Agreed. They are limited on the local machines to avoid the user from making system changes.

Where are the shares located? Users don't always have permissions to access certain file folders because they are system folders. Anything residing within a system folder is considered a child of the system folder and only power users and admins will be able to access them.

So, passed down permissions NTFS sets will explicitly deny users (not power users and admins) access to the share.

They are subfolders located in the root of D:

This is interesting:

The root of D: will not be a system folder. What do the "Effective Permissions" tell you for that user. Have you run effective permissions, yet?

Is it a hidden file folder, or designated as a system folder.

I think the lettering will appear blue on the file folder name if a system folder. You should be able to see if it's an admin share if it has a $ dollar sign in front of it. And if hidden, it will be seen within the file share attributes. Every one of these would hide the folder from browsing and also might prevent users from accessing them using the browser services.

Thanks for the input ChiefIT ... you seem to be the only one taking into account the differential that only those users in the Power User or Admin groups can browse via \\10.20.30.51 (as opposed to direct mapping via "net use").  To answer your questions:
1.) None of the shares end in $ (none hidden)
2.) None of the lettering is blue (it is black ... same as unshared folders)
3.) Attached is the NTFS, share, and effective permissions of one of the shares
CPCvol--user--Permissions.pdf

This is where a domain controller helps a lot. The domain controller is a centralized database of permissions and it makes all computers within the same group act as one.

Let's see if I remember this right.

The NTFS (Security) permissions are a combined conglomerate. This means if you have a group permissions of full control, but a user permission of read only for the same user, that user will have full control over the NTFS permissions. For simplicity, I like to view the NTFS permissions as permissions to access sectors of the disk.

The Share permissions grant access to the computer. Most permit access as full control to all file shares.

The way NTFS and Share permissions works is from a remote computer, the LEAST Permissable set will be granted for the user. So, as in your example, the share permissions are Read only, but the NTFS permissions are set to Read/Execute/transverse folders... etc... Taking the LEAST permissive set will give you the share permissions of the file (meaning READ ONLY).

Try to set your SHARE permissions to FULL Control for your users, then try to access and traverse the shares.
--------------------------------
NTFS>>>Most Permissions of all accounts on that file share
SHARE Permissions>>gives you a certain access
NTFS+++SHARE permissions>>LEAST PERMISSIVE SET

In your PDF, on the Share Permissions tab, add the group Users, and I'll bet it will start working.

I made it over to this facility today and tried giving all users full permission to the share (and took them out of the power users group).  Same error "Access Denied".  I thought we were on to something, but still no luck.

Remember on a domain environment, you have to authenticate with a centralized database of users and computers. When on a domain, there are two permissions sets that need to pass before you get a certificate that grants permission... Those two will be USER credentials, and COMPUTER credentials. Yes, the computer has a username/password as well. So, in order to access domain resources, the computer has to be a part of the domain.

In a workgroup environment, you don't have the centralized database. So, you are logging on with the users on that local machine:

Example:

machine1\user1
password for that user is: XXXYYYZZZ

That set of username and passwords needs to be ON machine 1.

Now, with your issue. I would like to explore CHILD permissions passed down from PARENT folders. Since these files are on the root of D:\, you might be getting passed down NTFS permissions to the users that allow ONLY admins and power users access. So, check the passed doqn permissions from the virtual drive of D:\

Chief IT:  When the security permissions were set on each folder, I unchecked the "Inherit tfrom parent the permission entries that apply to child objects.  Include these with entires explicitly defined here."  I also make sure to check "Replace permission entries on all child objects with entires shown here that apply to child objects".

You stated to "check the passed down permmission from the virtual drive d:\" - Please let me know where in XP Pro to check this and what to look for.  Would it be under "Security" --> "Advanced" --> "Permissions" tab --> "Inherited From "column?

Thanks again Cheif ... you seem to really know your stuff ... no wonder your rank is "Genius"

UNCHECKED:  Inherit tfrom parent the permission entries that apply to child objects.
>>UNCHECKED means that the permissions of the above parent folder will NOT be inhereted. So, these files, that reside on D:\, will not get that permissions set assigned to D:\.

 CHECKED: "Replace permission entries on all child objects with entires shown here that apply to child objects".

>>CHECKED: means that all child files and folders will get these permissions.

In other words you have three files:

Top-
----Central
----------Buried

If go to central and uncheck, ineretance from the parent folder, you will not get the permissions set from Top folder.

If you remain on Central and and Check "Replace permission entries on all child objects"... All files and folders within Central will get the permissions passed down to them from central. This includes the file folder called "Buried".

So, if you have administrators and power users on Central with full control, but explicit denies for anyone else to access/ browse/edit central, (and you pass down permissions from central), your users will not be able to access/browse/edit documents accordingly. Remember that NTFS explicit denies override permitted access.

Cheif IT:

I UNCHECKED the former listed above and CHECKED the latter.  This way I am certain "c'entral" and "buried" get what I assign and not what is "top"

You stated to "check the passed down permmission from the virtual drive d:\" - Please let me know where in XP Pro to check this and what to look for.  Would it be under "Security" --> "Advanced" --> "Permissions" tab --> "Inherited From "column?

Yes, it is an inherited permission set from above.

Yet, another thing you can do is check the NTFS permissions by performing an "Effective Permissions" on a user.

Effective Permissions is shown in screen shot in attached PDF above.  It does show the NTFS permissions are inherited from above (D:\).  but both are set for users to be able to read.

The users are locally stored on both the file server and thier machines (and simple file sharing is/has been disabled).  The usernames and passwords match on all machines.  Yes, would be easier w/ a DC, but this small non-profit can't justify nor support it.,   Thanks for all the help Cheif!

This is a strange and unique problem, that is either a bug or a strange registry or security policy setting that is wrong.  Cheif IT, you tried hard to narrow down the issue based on the true differential (Admins or Power Users only having access).

I have decided to reformat and try again.  Will start will base load + SP3, set all NTFS permissions and full share permissions to everyone.  If all is working, I will slowly start loading other software and see if there are any conflicts.  Thanks again Chief IT.  Points go to you.

Will reformat.