Windows 7 Win 7 Networking Permissions Issue

[GreyBat]

First of all, apologies if this has been raised before. I couldn't search through all the previous posts to find it or similar!

OK, I'm supporting a small office network - only 4 computers - 3 laptops and a desktop, acting as a server. All 4 machines are running Win 7 Pro, and all are connected, and all configured in the same workgroup. The network does not use a homegroup.

Various shares are configured on the server. Some allow "Everyone" full access, and some are restricted. Specifically, one user, named ED, is supposed to have full access to 2 shares on the server. A user, "ED", has been set up on the server with the login password she uses on her laptop. One of the shares works fine. She can see, read and update as she is supposed to from her laptop. Another share will not work. I cannot get access at all. ("Network Error: Windows cannot access \\SERVER\BadShare").

I have checked and rechecked the permissions for the 2 shares, and they seem to be the same. I have checked them via the Sharing properties of Explorer, both used Share With, and Advanced Sharing, and I have checked then through Shared Folders in Computer Management. I cannot see any significant differences (although I did find that the initial permissions set up through Share With did not synchronize to the permissions listed in Advanced Sharing. I have since aligned them manually.).

The only difference I notice is that, for the share that works correctly, the "Offline Status" seen in the client Explorer window shows "Online". For the share that does not work, the "Offline Status" line (below Offline availbility) is absent.

I do have some screen shots of this and will post them if it will help anyone. Right now I'm baffled and frustrated!

 

[Trouble]

Check NTFS permissions (folder (share), properties, security tab) and confirm that the user has explicitly been granted the access rights she needs and then double check both Share and NTFS permissions that there is not a "Group" with more restrictive rights to that particular share that she is a member of.
If she is a member of the "Users" group on the host / server machine and the group "Users" has been granted "Read", then all she will have is "Read" regardless of what she as a User has been explicitly granted to the shared resource.

 

[GreyBat]

Thanks for the quick reply, Trouble! I'll have a look tomorrow. I think I am confusing share permissions with NTFS permissions. But it is interesting that, if I add Everyone to the Share permissions, she can access the folder just fine!
Trouble is, so can everyone else.... of course!

 

[Trouble]

Typically you'll want to add everyone-> full control under the permissions tab. And then you'll want to be more specific with the NTFS permissions explicitly adding your users and giving them that access they need.
You'll likely want to avoid adding groups (excepting the administrators group) as cross group membership can result in access conflicts.
Remember Share Permissions are for people accessing files over the network, NTFS Security Permissions are for people setting at the computer and accessing files / folders. When they are combined and they always are then the most restrictive will apply.

An old reference but it still applies.

 

[GreyBat]

Thanks again for your help and advice.

I have achieved my objective, although not in the way you have suggested! And I don't understand how what I did to achieve said objective worked.

First of all, it occurred to me that, if I was trying to configure permissions for a user through NTFS permissions, these permissions should apply whether the user was logged in on the server desktop machine, or was coming in through the network. That was not the case. ED was getting the network error only on the network. ED could access the shares fine when logged in on the server.

I messed around a bit assigning Everyone to the network share and then trying to figure out how the NTFS permissions should work, but I couldn't achieve what I wanted. I did get rid of the network error, but I could not figure out how to configure the NTFS permissions correctly.

So, in the end, I took another tack. I created a new partition on the server (I, and moved the folder that I was working with to the new partition. I left the NTFS permissions as they were by default. I created a new share called "Backup I", added 2 userids to the network shares, these being SHAREPC (also the owner of the server) and ED. ED could not access the share, with the same network error as before. It looked to me as though the setup was more or less exactly the same as that for another shared partition (G:, with a share name of "Backup G") where I was having no trouble. I carefully compared NTFS permissions and network share permissions. There was one difference: a third local user account exists on the server machine, called "Confidential", also an Administrator account, but not logged on. This user had network share permissions to Backup G but not to Backup I. So I added this user to the network share for Backup I, and, bingo, the network error that ED was getting went away. ED can now see the Backup I share from the network, and the other users on the network cannot.

I would be very interested, if you have the time, if you (or someone else) could explain how adding another, unaffected user to the network share enabled the affected user to be able to see it!

 

[Trouble]

Hard to say as you do not have a server in place to handle authentication it's taken care of by what we generally refer to as Windows Pass Through Authentication.
My bet is that somehow the account "Confidential" is tied to the account that is being used on, for or by ED.
Check both machines, log off and then log back on and see what exactly is being typed as a user name and password (they need to be identical in both places)
Hold the Windows Logo Key and strike the R key and type
lusrmgr.msc
on both machines and check the user account properties
Finally on both machines check C:\Users for existing user profile folders and see what's what for actual identities in case an account was at some point actually renamed. Which might, I suppose be causing some issues on one or the other or both machines.

 

[GreyBat]

I think this might be related......

The user account "Confidential" on the server has, of course, its user folder, C:\Users\Confidential. There is also a share defined, called "Confidential" that provides permissions for ED (and SPAREPC) to access this folder. So, there is a user and a share with the same name.

Presumably this is not an ideal arrangement. I believe it was set up this way, before my involvement, with the intent of restricting access to user:Confidential's files (in actual fact, a single folder within the Documents folder in C:\Users\Confidential). I think I will move that folder elsewhere, then remove the Confidential account from the server, and the share.