Map a VPN file share with the Samba account the server knows

Connect the tunnel and the share still asks for a password the user believes is correct. In a standalone Samba deployment the VPN login and the SMB login are unrelated credentials: one authorizes the tunnel, the other is checked by the file server. Mapping the drive with the VPN account therefore fails even when the password is right and the network path is perfect. That distinction explains most mapping failures over a VPN.

The fix is not to reset the VPN account. It is to name an identity the Samba server actually knows, then check that the same identity has share and directory rights.

The VPN login and the SMB login are different identities

A VPN account is evaluated by the VPN gateway under its own policy. It answers whether this client may enter the private network. It says nothing about which SMB account exists on a file server inside that network.

A Samba account lives in the server's authentication backend, with its own password database and its own name. Two machines can both have a user called alice without sharing an identity system, a password or a user identifier. The names match; the accounts do not.

A domain-integrated Samba server changes the picture: the identity comes from the directory and Kerberos, not from a local account list. In that case use the directory identity and the supported SMB configuration rather than creating local duplicates to imitate domain membership. Check which model the server uses before creating any account.

See which identity Windows is actually using

Windows caches connections per server. If an existing session to the same server was opened with another account, a new mapping can reuse that session or fail with an authentication error that names the wrong user. That is how a correct password comes to look wrong. Inspect the current connections before changing credentials.

net use
cmdkey /list
klist

The first command shows mapped drives and open sessions, the second shows stored credentials that may be applied automatically, and the third shows Kerberos tickets when a domain is in use. A stored credential can silently override the account you intended to type.

Remove only the connection or credential that belongs to this problem. Disconnecting every drive or replacing the server name with an IP address hides the identity choice and can break signing or name-based policy.

Map the share with the server-recognized account

Supply the account in the form the server expects and let Windows prompt for its password, so the secret does not land in command history or a script:

net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no

The server component before the backslash is the Samba server's identity context, not the VPN gateway. The asterisk requests an interactive password prompt, and /persistent:no keeps the mapping out of the next sign-in. Choose a drive letter that is free.

If the server is domain-integrated, the user component may be a directory name or a domain-qualified identity instead. Use the form the administrator documents; inventing a local account with the same name creates a second identity and a second password to maintain.

Account validity, share access and filesystem rights are three checks

Samba checks whether the identity authenticates, whether the share definition admits it, and whether the filesystem grants the requested operation. Passing the first check does not imply the other two. A share can be visible and still refuse writes because the directory permissions say so.

A share restricted with valid users admits only the listed accounts or groups. The account may authenticate correctly and still be rejected by that line. Check the share definition before concluding that the password is wrong.

On the filesystem side, the Samba process and the mapped identity both matter. A directory owned by root with mode 700 will not accept writes from an ordinary account even when the share definition allows it. Test with a read, then a write, in a directory the account is supposed to use.

Clear a conflicting session without breaking policy

When a stale session is the cause, close that one connection and map again with the intended account. If a stored credential keeps returning, remove that credential rather than the whole drive list. Then confirm the new session with net use.

Keep the required SMB signing, encryption and account policy in place. A server that refuses an unsigned or unencrypted session is enforcing policy, not misreading the password, and weakening it to make the map succeed trades security for a symptom.

Record the server name, the exact account form and the share and directory rights that worked. The next person to map the drive will otherwise retry the VPN login first, because that is the credential they used to reach the network.