Samba共享挂载出现mount error(13)权限被拒求助

Alright, let's dig into why you're getting that mount error(13): Permission denied even though your Samba config and fstab look correct. This is a super common issue, and usually boils down to one of these easy-to-miss details:

1. Make Sure Samba Users Are Properly Set Up #

First off: Samba has its own user database that's separate from your system's user accounts. Even if users A and B exist on your server, you need to add them to Samba and set a password for each:

sudo smbpasswd -a A
sudo smbpasswd -a B

Double-check that you're using the exact same password when mounting—even a tiny typo here will block access.

2. Fix File System Permissions on the Shared Directory #

Your Samba share points to /myshare, but the underlying Linux file system might be blocking access. Run this to check the current permissions:

ls -ld /myshare

Users A and B (or a group they both belong to) need at least read and execute access to this directory. If they don't, fix it with:

# If A and B are in a common group (e.g., "smbusers")
sudo chown -R :smbusers /myshare
sudo chmod -R 750 /myshare

# Or if you want to give user A ownership directly
sudo chown -R A: /myshare

3. Double-Check Your smb.conf for Typos #

Let's revisit your config snippet:

[myshare]
comment = My Share (restricted)
path = /myshare
browsable = no
writeable = yes
valid users = A, B

Wait—see that space after the comma in valid users = A, B? That's a problem! Samba will interpret " B" (with a leading space) as a separate user that doesn't exist. Fix it to:

valid users = A,B

After making any changes to smb.conf, restart the Samba services to apply them:

sudo systemctl restart smbd nmbd

Also, run testparm to check for any other syntax errors in your config—it'll catch typos you might have missed.

4. Rule Out SELinux or AppArmor Interference #

If you're running a system with SELinux (like RHEL, CentOS, or Fedora), it might be blocking Samba from accessing /myshare. Temporarily set SELinux to permissive mode to test:

sudo setenforce 0

If the mount works now, you'll need to set the correct SELinux context for the shared directory to make the fix permanent:

sudo semanage fcontext -a -t samba_share_t /myshare
sudo restorecon -Rv /myshare

For Ubuntu/Debian systems using AppArmor, check if the Samba profile is restricting access and adjust it accordingly.

5. Clean Up Your Client Mount Options #

In your fstab line, you're using username='A' with single quotes. Try removing those quotes—they can cause unexpected issues in some environments:

//server/myshare /theshareplace cifs file_mode=0777,dir_mode=0777,username=A,password=pss 0 2

Also, when mounting manually, make sure you're using the correct case for the username—Samba is case-sensitive by default, so a is not the same as A.

6. Check Samba Logs for Exact Error Details #

If none of the above fixes it, let's look at the server logs to get the full picture. Run this on your Samba server:

sudo tail -f /var/log/samba/log.smbd

Then try mounting from your client again. The log will show exactly why access is being denied—whether it's an invalid user, wrong password, or file permission issue. This is usually the fastest way to pinpoint the problem.

内容的提问来源于stack exchange，提问作者ca55idy