leapconsulting
asked on
Windows 7 x64 machines unable to access single fileshare on server by netbios name
We have a very strange problem we have just commissioned a new data server running Windows Server 2008 R2 (It is a VM running on Citrix Xenserver 6.0.2)
We have some Windows 7 x64 machines that refuse to connect to a single share on this server but only when the netbios name is used.
For example if someone from an affected machine tries to connect to
\\SERVERNAME\share$ they get an access is denied error
if they access \\SERVERNAME.domain.local\
The issue is PC specific and not dependant on who is logged in. Share permissions are all users Full Access and NTFS permissions allow everyone read/write access (which is verified by the fact it is accessible by accessing the same share but using the servers FQDN.)
The share in particular is being used for user accounts redirected folders (start menu, application data, desktop etc.)
For the moment I am updating GPO's to use the FQDN but to me this is working around the issue instead of resolving it.
We have some Windows 7 x64 machines that refuse to connect to a single share on this server but only when the netbios name is used.
For example if someone from an affected machine tries to connect to
\\SERVERNAME\share$ they get an access is denied error
if they access \\SERVERNAME.domain.local\
The issue is PC specific and not dependant on who is logged in. Share permissions are all users Full Access and NTFS permissions allow everyone read/write access (which is verified by the fact it is accessible by accessing the same share but using the servers FQDN.)
The share in particular is being used for user accounts redirected folders (start menu, application data, desktop etc.)
For the moment I am updating GPO's to use the FQDN but to me this is working around the issue instead of resolving it.
Last Comment
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Hi, yes all 3 resolve to the same IP. Please note this is only affecting one share on a server that hosts many. So the affected clients can access different shares on the same server.
Also as a further update as of yesterday afternoon some of the afflicted PC's are also unable to connect via FQDN to this particular share. So now
\\servername\share$ gives an access denied
\\servername.domainname.lo
\\IPADDRESS\share$ works
So the issue appears to be progressing, also after taking a tally of the affected machines the only ones affected are Windows 7x64 machines that are in branch offices (Windows 7 x64 machines in the same office as the file server work without issue as does all Windows XP machines regardless of physical location. All branch offices are connected to the central office by way of IPSEC VPN's hosted on SonicWALL UTM units (nothing is showing in the logs of these that might suggest something is being blocked and for good measure we have temporarily disabled any of the UTM features of these units to ensure Gateway AV or Intrusion prevention was preventing access, so far this does not appear to change anything.
Also as a further update as of yesterday afternoon some of the afflicted PC's are also unable to connect via FQDN to this particular share. So now
\\servername\share$ gives an access denied
\\servername.domainname.lo
\\IPADDRESS\share$ works
So the issue appears to be progressing, also after taking a tally of the affected machines the only ones affected are Windows 7x64 machines that are in branch offices (Windows 7 x64 machines in the same office as the file server work without issue as does all Windows XP machines regardless of physical location. All branch offices are connected to the central office by way of IPSEC VPN's hosted on SonicWALL UTM units (nothing is showing in the logs of these that might suggest something is being blocked and for good measure we have temporarily disabled any of the UTM features of these units to ensure Gateway AV or Intrusion prevention was preventing access, so far this does not appear to change anything.
Go to the network properties on one of the affected machines and uncheck IPV6 as a test.
ASKER
No change with disabling IP v6, at the moment we have reimaged one of the affected machines and it seems to be playing ball, that said I would still like to find the root cause just in case this crops up again I would like to avoid reimaging every single time.
Did you look at my post?
Microsoft Legacy OS
The Microsoft Legacy Operating System topic includes legacy versions of Microsoft operating systems prior to Windows 2000: All versions of MS-DOS and other versions developed for specific manufacturers and Windows 3/3.1, Windows 95 and Windows 98, plus any other Windows-related versions, and Windows Mobile.
55K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
2 & 3 should give you the same results; but, is the ip of <servername> different?
If so, go to your DNS server and add the computer as a record.