Share Stopped Working After a Windows Password Change
Nothing on the Ubuntu side changed. Nothing on the share changed. But the password on the Windows PC did - and Ubuntu, faithful as ever, keeps offering the old one from the credentials file and being refused. This is the most common sudden breakage of a permanent mount, and the fix takes two minutes.
Technical AnshuUbuntu and WindowsStep-by-step guide
Watch the video for the complete process shown live, step-by-step
Permanent mounts fail in a particular, misleading way: they work perfectly until one ordinary event on the Windows side - a password change, a forced expiry at the office, switching from a local account to a Microsoft account - and from that boot onward the mount reports permission denied. It feels like Ubuntu broke. In truth Ubuntu is doing exactly what it was told, with a credential that stopped being true. The credentials file is a copy of the password, and copies go stale. This page updates the copy, remounts cleanly, and then removes the monthly repeat by changing which account the share uses.
The pattern - how a healthy mount breaks without anything failing
For weeksShare mounts at every boot
One ordinary dayPassword changed on the Windows PC
From that bootMOUNT ERROR 13
The fixOne line inside /root/.smbcredentials
✓ The credentials file holds a copy of the password - and copies go stale quietly
The timeline to recognise. If the breakage date matches a password change on the Windows PC, you already have the diagnosis.
1
Step 1 - Recognise the Pattern Before Rebuilding Anything
Resist the urge to redo the whole setup. The signature of this problem is precise: a mount that worked, broke suddenly, and now gives permission denied (mount error 13, STATUS_ACCESS_DENIED in the log) while the share still opens fine from Windows itself.
Ask the one question that matters: did the password of the share account change around the day it broke - including an office policy forcing a change, or someone tidying up accounts on that PC
Do not let the PIN confuse the investigation. Changing the Windows Hello PIN does not change the password, so a PIN change alone cannot cause this - a password change can
If the account became a Microsoft account, remember the share now authenticates with the Microsoft account password, whatever the login screen shows
2
Step 2 - Update the One Line in the Credentials File
The stale copy lives exactly where you put it.
Open the file: sudo nano /root/.smbcredentials
Replace the password on the password= line with the current Windows password - carefully, keeping the same format: no spaces around the equals sign, no quotes
Save and exit. The permissions stay 600; editing with sudo nano does not change them, but a glance with sudo ls -l /root/.smbcredentials costs nothing
If the user name changed too - a renamed account, a new dedicated account - update the username= line in the same visit
3
Step 3 - Remount Cleanly So the New Credential Is Actually Used
An already-mounted or half-failed mount can keep the old state. Clear it and mount fresh.
Unmount: sudo umount /mnt/SharedDocs
If it answers that the target is busy, close whatever is using files from the share and try again - a terminal sitting inside the folder counts as using it, so cd out first
Mount again with the file: sudo mount -a
Verify with evidence, not hope: ls /mnt/SharedDocs and open a file. The permission error should be gone
4
Step 4 - Stop the Monthly Repeat - Give the Share Its Own Account
If the share signs in with someone's everyday Windows account, every password change that person makes will break the mount again - silently, on a random morning, forever. Offices solve this by giving the share a dedicated account on the Windows PC: a local user created only for sharing, with its own long password, listed in the share and NTFS permissions, and not used for daily sign-in.
Create the account on the Windows PC, set its password, and make sure the setting that forces password changes on that account is off - a service account whose password expires is this problem on a timer
Point the credentials file at the new account once, and future password habits of the human users stop mattering
While you are on the Windows PC: remove any old password Ubuntu may also have saved in the Files app keyring, so quick connections stop offering the stale one too
🔴 The lesson underneath the fix: a permanent mount quietly couples two machines' account hygiene. Every secret stored in two places - the account itself and a credentials file - becomes a small synchronisation job you own. Dedicated share accounts shrink that job to almost nothing, which is why they are standard practice and not over-engineering.
Watch the Complete Video Guide
Watch the video for the full setup, then keep this page for the day a password change breaks it - it is a two-minute fix once you know where the copy lives.
I changed only my Windows PIN, not the password. Can that break the mount?
No. The PIN is a local sign-in convenience guarded by the machine itself; network authentication never uses it. If the mount broke at the same time, something else changed - usually the account password was reset during the same settings visit, or the account was converted to or from a Microsoft account. Check what the PC now expects by signing in elsewhere with the password itself.
Where else can the old password be hiding on the Ubuntu side?
In the Files app's saved connections. GNOME stores those credentials in your login keyring, and a saved server entry will keep offering the old password. Open Passwords and Keys, find the entry for the server, and update or delete it - after that the Files app and the fstab mount will agree again.
The new password works from another PC but the mount still fails. What now?
Then the credentials file itself is suspect: a trailing space on the password line, quotes typed around the value, or the edit never saved. Retype the two lines cleanly, and confirm the remount actually happened - unmount first, then mount -a, since an already-active mount ignores the updated file completely.
This guide is based on the Technical Anshu video on mounting a Windows share in Ubuntu - stuck on any step, ask in the video comments and you will get an answer.