Permission Denied on a Windows Share From Ubuntu The Two Locks Explained
The network is fine, the password looks right, and Ubuntu still answers mount error(13): Permission denied. Windows is not being stubborn - it is checking two locks you may not know are separate, plus an account and a modern guest rule. Here is the order to check them in.
Technical AnshuUbuntu and WindowsStep-by-step guide
Watch the video for the complete process shown live, step-by-step
Permission denied is the error everyone gets and nobody can aim at, because Windows applies two independent permission systems to a shared folder: the share permissions on the sharing itself, and the NTFS permissions on the files. Your access is whichever of the two is MORE restrictive - pass one, fail the other, and the door stays shut. Add three account traps and the guest-access block built into modern Windows, and this single error code has five honest causes. This page walks them in the order a technician checks them, starting with proving what the error actually is.
Terminal - what mount error 13 actually reports (example output)
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
The kernel log names it plainly
CIFS: Status code returned 0xc0000022 STATUS_ACCESS_DENIED
✓ This wording means authentication or permission - not a network failure and not a wrong share name
Example output. Error 13 with STATUS_ACCESS_DENIED tells you the server was reached and answered no - which is why the fix lives on the Windows side, not in your cables.
1
Step 1 - Confirm the Error Is Really Permission Denied
Aim before you fix. Run the mount and read the newest kernel messages.
Try the mount: sudo mount -a and note the exact error number
Read the log: sudo dmesg | tail - a line like STATUS_ACCESS_DENIED confirms the server refused the logon or the access
Different wording means a different page: error 2 or No such file or directory points at a wrong share name; Host is down points at the network or a sleeping PC - do not spend permission fixes on those
2
Step 2 - Lock One, the Share Permissions
On the Windows PC, this is the permission attached to the sharing itself, and it is the one people forget exists.
Right-click the folder, Properties, Sharing tab, Advanced Sharing, then Permissions
The account Ubuntu signs in with must be listed - directly or through a group - with at least Read, and Change if Ubuntu should save files
The classic setup error: sharing the folder with a quick Share button, which sets share permissions for a different account set than you expect. Advanced Sharing is where the real list lives
3
Step 3 - Lock Two, the NTFS Permissions
Same Properties window, Security tab - this is the permission on the files themselves, and it applies to local and network users alike.
The same account needs its NTFS entry too - Read and execute to open, Modify to save and delete
The rule that explains every confusing result: effective access is the more restrictive of share and NTFS combined. Full control on the share plus Deny or absence in NTFS still equals no
Watch for inherited denials on folders moved from another disk or created by another account - the Security tab shows them plainly
4
Step 4 - The Account Traps - Password, Microsoft Accounts and Names
If both locks look right, interrogate the account itself.
Blank password: Windows refuses network logons for accounts with no password, by policy. Give the share account a real password - that is the fix, not a workaround
Microsoft account sign-in: the PC may sign in with a PIN or face, but the share still authenticates with the account password and its user name - which for a Microsoft account is often not what the login screen shows you. The local name appears in C:\Users as the profile folder name
Name format: if the plain user name fails, the credentials file can carry the machine-qualified form with a domain line: domain=OFFICE-PC alongside the user name
5
Step 5 - The Guest Wall in Modern Windows
Windows 11, and recent Windows 10 builds, block insecure guest logons to shares by default. A share set up as open - no account, everyone welcome - is exactly what that policy refuses, and Ubuntu receives the same error 13. The honest fix is not to weaken Windows: give the share a real account with a password, list that account in both locks above, and put it in the credentials file. Older guides that tell you to re-enable guest access are asking you to reopen a door Microsoft closed because attackers walked through it.
Test the theory fast: from another Windows PC, the open share fails the same way - proof it is policy, not Ubuntu
Printers and scanners that scan to a folder hit this same wall - they need the dedicated account too
🔴 Do not fix this by weakening the wrong machine. Registry tricks that force Ubuntu to offer older, weaker authentication, or Windows tweaks that restore guest access, both trade a real security boundary for one afternoon's convenience. Two permission tabs and one proper account fix error 13 permanently, on every client, with nothing weakened anywhere.
Watch the Complete Video Guide
Watch the video to see the share created on Windows and mounted in Ubuntu - the permission settings on the Windows side are shown there.
The share opens from another Windows PC but not from Ubuntu. Why?
Windows-to-Windows often succeeds silently with your signed-in credentials passed through automatically, which can hide a permissions gap. Ubuntu always presents exactly the account in the credentials file - so it exposes which account really has access. Check the two locks for THAT account, and try the machine-qualified user name if the account is local to the Windows PC.
Why does Ubuntu keep asking for a password, or fail right after I type it?
A password prompt that loops usually means the offered credentials were rejected, not that the prompt is broken - wrong password, a stale one in the credentials file after a Windows password change, or the user name format. A dedicated page in this series covers the password-change case, which is the monthly classic in offices.
I can open and read files but saving from Ubuntu fails. Which lock is that?
That split - read yes, write no - is a permission level, not a connection problem. Either the share permission is Read only, or the NTFS entry lacks Modify. Fix the level in whichever tab is set lower; the effective access follows the more restrictive of the two, so raise the one that is holding it down.
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.