Azure file shares can authenticate in two ways, and your two laptops might be using different ones. When authentication falls back to classic SMB username and password, Windows expects the storage account name as the username and the storage account key as the password. If the second laptop keeps rejecting your credentials, it is often because Windows is silently using a conflicting cached credential from Credential Manager or attempting a different credential set before applying what you type. Removing any saved credentials for the storage endpoint, rebooting, and retrying typically resolves that. SMB 3.0 support and accurate system time also matter, since Azure requires encrypted SMB sessions and rejects requests from devices with clock drift.
Azure Files can also authenticate with Entra ID. When this is working, you never enter a username or password because Windows obtains a Kerberos ticket tied to your Entra ID or hybrid-joined identity. If one laptop maps the share without issue and the other prompts for credentials, it means the working device is receiving a Kerberos ticket while the failing one is not. That usually happens when the device is not properly Entra ID joined, is signed in with a different identity, cannot reach the required Entra ID endpoints, or does not have the right RBAC permissions. In that case, the system drops to classic SMB authentication, which then fails unless you supply the storage account credentials exactly as Azure expects.
If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
hth
Marcin
and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.