1

I have an Azure VM setup (dev1) and I cannot access a shared folder (publish) via UNC path from my workstation. I am connected to Azure over a P2S VPN connection and my workstation is in the same domain as the Azure VM. When I open explorer and try to access \dev1\publish, I get an error saying:

\\dev1 is not accessible.  You might not have permission to use this network resource.  
Contact the administrator of this server to find out if you have access permissions."

The user name could not be found.

I am logged in to my workstation as a domain user and am never prompted to enter different credentials. Am I misunderstanding how to access a file share on an Azure VM?

1
  • I am getting this same error in 2022, so if anyone has found a solution that would be great! Same scenario. Laptop connected using Azure P2S vpn. File share hosted in Azure VM - even the domain GPO SYSVOL is inaccessible (also hosted in Azure). If I access the fileshare using the short name, \\hostname, I get the error. But if I access it via the fqdn, I get access. \\hostname.domain.com. Can't for the life of me figure this out. Nov 23, 2022 at 18:10

3 Answers 3

1

If the Azure VM is a Windows Server, make sure you've enabled the File Server role, which will allow SMB traffic thru the Windows firewall.

0

Are you sure you are logged in as a domain user? Where is the domain controller; is it an Azure VM? Try adding a read permission to the file share for "Everyone", which is really wide open, but which should allow you to confirm the connectivity is good. From what I remember, Windows authentication for file sharing doesn't work well through multiple networks and routers. If your VPN is supposed to resolve that, maybe the network settings on one or more machines is not set up for a VPN network address (e.g. a broadcast address on the VPN versus the real network).

0

This answer sucks, but it's a temporary work-around. The network credentials appear to be trashed when you join the network. I'm unsure of the exact details, but it looks like it tries to authenticate the client cert that you used (which is probably self-signed) and fails. The work-around involves disabling the cached client credentials so that the fail-over will kick into gear and it will use Kerberos to authenticate.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa set disabledomaincreds - Set the value to 1

Like I said, I hate the work around, but it will allow you to get to first base if you don't mind typing your credentials in each time you want to connect to a VM.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .