Fix Samba Permission Denied Error When Copying Files from Windows 11

You can open a Samba share from Windows 11, see all your files, and read them without any trouble. Then you try to copy a new file into the folder, and Windows stops you with a blunt message: permission denied. It feels unfair, because the share is clearly working. In reality, Samba checks permission in more than one place, and passing the first check does not mean you will pass the second.

This guide explains why the error happens and walks you through the fixes in the right order. You will check the share settings on the Linux side, the folder permissions underneath them, and the account Windows is actually using.

Quick Answer

A permission denied error when copying to a Samba share usually means the folder on the Linux machine is not writable by the Samba user you signed in with, or the share itself is set to read-only. Open smb.conf, make sure the share is not marked read only = yes, then set the Linux folder permissions so your user owns it or belongs to a group with write access. Restart Samba with sudo systemctl restart smbd and copy the file again.

Understand the Three Layers of Samba Permission

Samba does not invent its own permissions from nothing. It sits on top of normal Linux file permissions, and Windows adds a third factor: the identity it presents when it connects. If any layer says no, the copy fails, even if the other two layers say yes.

Layer one: the share definition

The share definition in /etc/samba/smb.conf decides whether a share is offered as writable at all. A line such as read only = yes or the missing opposite, writable = yes, will block every write no matter how open the folder is underneath. Guest shares have their own trap: guests are mapped to a low-privilege account that often owns nothing.

Layer two: Linux folder permissions

Underneath Samba, the actual directory must allow writing. If the folder is owned by root and set to 755, only root can add files. Your Samba user can read everything and still be refused when creating a new file.

Layer three: the Windows identity

Windows 11 often connects silently with cached credentials, a Microsoft account, or even a guest session. You may think you are signed in as your server user, while Samba sees a completely different name. Checking who you really are on the connection saves a lot of guessing.

Step 1: Check the Share Is Writable in smb.conf

Start on the Linux machine or NAS that hosts the share.

1. Open the Samba configuration file with sudo nano /etc/samba/smb.conf.
2. Find the section for your share, shown in square brackets, for example [Shared].
3. Look for lines about writing. You want read only = no or writable = yes. These two settings mean the same thing stated in opposite ways, so use only one of them.
4. If you use a valid users list, confirm your username appears there, for example valid users = yourname.
5. Save the file and test the configuration with testparm -s. This command prints errors if the file has a typo.
6. Restart the service with sudo systemctl restart smbd so the new settings take effect.

The official Samba wiki guide to setting up a standalone server explains each of these share options in detail if you want to review what your file should look like.

Step 2: Fix the Folder Permissions on Linux

Next, make sure the folder itself allows your user to write. Suppose the share points to /srv/shared and your Samba username is the same as your Linux username.

1. Check the current owner and permissions with ls -ld /srv/shared.
2. Give ownership to your user with sudo chown yourname:yourname /srv/shared.
3. Set sensible permissions with sudo chmod 775 /srv/shared. This lets the owner and the group read, write, and enter the folder, while others can only read.
4. Apply the same thinking to subfolders you copy into. A writable parent does not fix a read-only child folder created by root or by another program.
5. Test locally before blaming Windows. Run touch /srv/shared/test.txt as your normal user. If that fails on Linux itself, Samba was never the problem.

For shared family folders, a group approach works better than a single owner. Create a group, add each user to it, and set the setgid bit with sudo chmod 2775 /srv/shared so new files inherit the group automatically.

Step 3: Confirm the Samba Password and User Exist

A Linux user is not automatically a Samba user. Samba keeps its own password database, and a missing or mismatched entry can push Windows into a guest or failed session that reads but cannot write reliably.

1. List Samba users with sudo pdbedit -L and confirm your name is present.
2. If it is missing, add it with sudo smbpasswd -a yourname and set a Samba password when prompted.
3. If it exists but you suspect a mismatch, reset it with sudo smbpasswd yourname.
4. Make sure the account is enabled. A disabled account shows a D flag in the detailed listing from sudo pdbedit -Lv yourname.

Step 4: Reconnect From Windows 11 With the Right Account

Now clear the old connection on the Windows side so it stops reusing the wrong identity.

1. Open Command Prompt and run net use to see existing connections to the server.
2. Disconnect the share with net use \\SERVER\Shared /delete, replacing the names with your own.
3. Open Credential Manager, choose Windows Credentials, and remove any saved entry for the server if it holds an old password.
4. Reconnect by typing \\SERVER\Shared in the File Explorer address bar.
5. When prompted, enter the Samba username and the Samba password you set in the previous step, and tick the box to remember them only after the copy test works.

If Windows refuses to show a login prompt at all, it may be falling back to guest access, which many servers block or restrict. That behaviour is covered in our related guide on how to map a network drive in Windows 11 step by step, which also helps you make the connection permanent.

Step 5: Check for Special Cases

SELinux or AppArmor blocking writes

On Fedora and Red Hat based systems, SELinux can deny Samba writes even when normal permissions look perfect. Check the audit log, and if needed label the folder for Samba sharing with the context tools your distribution provides. On Ubuntu, AppArmor rarely blocks standard share paths, but custom paths outside the home directory are worth checking.

Read-only files copied from elsewhere

Sometimes the folder is fine and the file is the problem. Files copied from a DVD, an old backup, or certain download tools can carry a read-only attribute. Right-click the file in Windows, open Properties, and clear the Read-only box, or fix the source folder permissions on Linux with chmod -R u+w /path/to/files.

Disk or filesystem limits

A full disk, an exceeded quota, or a filesystem mounted read-only after an error will also produce access failures. Run df -h to confirm free space, and check mount output to be sure the drive is mounted with rw rather than ro.

Common Mistakes and Useful Tips

• Editing smb.conf but never restarting Samba. Changes do nothing until the service restarts or reloads.
• Setting permissions to 777 as a first move. It may work, but it gives every local user and process full access. Fix ownership and group membership instead.
• Testing with a different account than you think. Cached Windows credentials are silent. Always disconnect and reconnect cleanly when testing.
• Forgetting subfolders. The share root can be writable while the one folder you need was created by root through another tool.
• Changing the Samba password but not the saved Windows one. Update Credential Manager after every password change, or Windows keeps sending the old password.
• Tip: keep a small test file habit. After any change, copy one tiny text file first before moving a large folder of photos.

Conclusion

Permission denied on a Samba share is rarely a mystery once you check all three layers in order: the share must be writable in smb.conf, the Linux folder must be writable by your user or group, and Windows must be signed in as that same Samba user. Work through the steps above, restart Samba after configuration changes, and reconnect from Windows with fresh credentials. That methodical pass fixes the great majority of cases without weakening security or opening the folder to everyone.

Frequently Asked Questions

Why can I read files but not copy new ones to the share?

Reading and writing are separate permissions. Your account passes the read check but fails the write check, usually because the folder is owned by another user or root, or because the share is set to read-only in Samba.

Does chmod 777 fix Samba permission denied errors?

It often removes the symptom, but it is a poor fix because it grants full access to every local account. Changing ownership to your user, or using a shared group with 775 or 2775 permissions, solves the problem safely.

Why does Windows not ask me for a username and password?

Windows reuses saved or silent credentials, including guest sessions. Disconnect the share with net use, remove the saved entry in Credential Manager, and reconnect so Windows prompts you again.

Do I need to restart the whole server after editing smb.conf?

No. Restarting only the Samba service with sudo systemctl restart smbd is enough, and it takes a few seconds. Existing connections may need to reconnect afterwards.

Can a full disk cause a permission denied message?

Yes, Windows sometimes reports a full disk or a read-only filesystem mount as an access problem. Check free space with df -h on the server before spending more time on permissions.