none
Windows 7 Ent. to 2012 Share - Windows cannot access \\server\share$ RRS feed

  • Question

  • I've got a strange problem dealing with a 2012 R2 share.  We have a lab with 30 Windows 7 Enterprise workstations.  They all have the same desktop via a GPO applied folder redirection to a share on the above mentioned 2012 R2 server.  All but 4 of them can connect and pull the desktop with the appropriate shortcuts, network folders, etc.

    So the share permissions have no explicit denies.  In an effort to resolve this issue I've added both Everyone and Authenticated Users with Read permissions on top of the appropriate AD Group object that already had Read permissions and of course SYSTEM and Domain Admins with Full Control.  The NTFS permissions have of course CREATOR OWNER, SYSTEM, and Domain Admins with Full Control.  The appropriate AD Group also has Read permissions.  No explicit NTFS denies either.

    Using either the same account that belongs to the appropriate AD Group or my Domain Admin account (which doesn't have the redirected desktop) I can login to all workstations and all but the above mentioned four get the folder redirected desktop.  When I authenticate with my DA account and try to connect to the share on those four computers I get the same error the user gets:

    Network Error

    Windows cannot access \\SERVER\Share$

    You do not have permission to access \\SERVER\Share$.  Contact your network administrator to request access.

    I think we've all seen this error before.  But I've only seen it associated with NTFS or share permission problems.  Frankly I'm stumped.  Any ideas on what's going on?

    Edited to add:  I don't think it's a problem with the share.  Clearly it's a workstation issue since 26 of the 30 Win 7 machines can connect without difficulty.  And I don't think it's a profile issue either since I've never authenticated on these workstations with my domain account.

    Friday, July 22, 2016 3:56 PM

All replies

  • Hi E-95,

    According to your description, I suggest that we could try the KB about Cannot access shared files or folders on a drive in Windows Server 2012 or Windows Server 2012 R2.

    https://support.microsoft.com/en-us/kb/2957623

    Also we could make sure ntfs security which has been configured. Properties > Security > Edit > Add > Enter "Everyone".

    http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/you-do-not-have-permission-to-access-pcname/baa06630-4d3d-4ba2-837a-b087bd21cdb3

    1. Create a user account if needed.

    2. Go to the folder's sharing option, mark it shared, and assign permissions.

    3. On the remote computer, using the file explorer, type in

    \\<computer_name>\<share>

    substituting the "computer_name" and "share"" with the main PC's computer name and share name you created and when promted for username and password, use the account information you did in step 1.

    Hope it will be helpful to you


    Please mark the reply as an answer if you find it is helpful.

    If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Monday, July 25, 2016 9:32 AM
    Moderator
  • You have described the issue in detail and it seems like a strange such. In order to narrow down the issue do multiple tests:

    1. Exchange one working computer's and a failing one's ethernet cable connections and test to connect.
    2. Create a new share as a test and compare connecting to it with a working machine and a failing one. Compare the outcome with your real case.
    3. Depending on your skills, use Wireshark to compare the network communication between a working and a failing machine.
    4. .. etc ...


    Best regards, George



    Monday, July 25, 2016 3:18 PM
  • Hi Carl, thanks for the response.  Unfortunately neither one of those solutions resolved the issue.  However along the way I discovered what may be another clue to the problem.

    These are lab computers used in an elementary school.  The start of fall classes is rapidly approaching and with other tasks to complete I decided it's fourth down and long . . . it's time to punt by simply placing a copy of all the shortcuts in the C$\Users\Public\Public Desktop folder.  My thought being that until I can get an imaging solution in place those four computers can utilize the local shortcuts and if we add applications during the semester we can simply manually add the shortcuts on those four in addition to placing them in the redirected network share.

    However, after I copied the shortcuts to the Public Desktop, I went to confirm they were there on the workstation with the student account I'm using for testing logged in.  The shortcuts aren't there.  I do see them when I manually navigate to the Public Desktop folder on the system partition.  But they aren't showing up on the student's desktop.

    Again, I'm thinking this has to be a workstation problem.  I checked and confirmed they're getting all the same GPO's that the functioning workstations get.  They all exist in the same OU.  They're all members of the same AD groups.  I checked and confirmed that all the local workstation groups are empty except Users containing Authenticated Users, Domain Users, and INTERACTIVE (and of course Administrators has the local admin and DA accounts).

    So now I'm not even left with the punting option.  The problem has to be resolved prior to start of classes.  Any further ideas?


    • Edited by E-95 Monday, July 25, 2016 6:56 PM
    Monday, July 25, 2016 6:55 PM
  • Hi George, I tried all the things on your list except for the packet capture.  Mainly because I've devoted far too much time to this already as it is.

    1. Patch cable and network drop doesn't matter.  The offending workstation refuses to connect to that share with either the user's account or my Domain Admin account.  I can however connect to the administrative share for the server drive with my Domain Admin account and navigate to the directory I need.
    2. Scenario two, both machines connect fine.  It's not that the computers can't connect to shares.  They just can't connect to that particular share for some reason.
    3. Not packet sniffing.  In fact this may just go down as an unsolved mystery like Jimmy Hofffa.  I'm swapping the workstations out for some in the library that are only used for browser based education.

    I'll probably hold onto one of the drives and work on it after classes start and things die down a little.  Unfortunately there's just far too much to do now and I can't devote any more time to this.

    Paul

    Tuesday, July 26, 2016 2:15 PM
  • Ok

    1. Is the name of the share special in any case (apostrophes, spaces etc...)?
    2. Same language on all machines?

    Best regards, George

    Tuesday, July 26, 2016 3:31 PM
  • The share name does have a space in it.  The actual share is \\SCHOOL\Student Desktop$.  And now that you mention it I seem to have some vague recollection from my MCSE tests that share names shouldn't have spaces in them.  I've been a large corporation AD & PKI guy for the past few years and haven't had to support file & application servers for a while.  New job, new pre-existing environment here.
    • Edited by E-95 Tuesday, July 26, 2016 3:44 PM
    Tuesday, July 26, 2016 3:43 PM
  • Well, with Wireshark you surely can spot those connection errors

    Best regards, George

    Tuesday, July 26, 2016 3:47 PM