If you recently updated your RedHat or CentOS 7.6 system, you may suddenly start getting “Permission Denied” errors when attempting to mount SMB shares via CIFS. Typical error messages in syslog look like this:
kernel: Status code returned 0xc000006d STATUS_LOGON_FAILURE kernel: CIFS VFS: Send error in SessSetup = -13 kernel: CIFS VFS: cifs_mount failed w/return code = -13
Configuration that triggered the problem
- Synology NAS with latest operating system shares a volume via SMB
- CentOS 7 Linux server mounts SMB share using a local username and password (NOT domain credentials)
- cifs-utils version 6.2 installed in May of 2019 (this by itself worked fine)
- libsmbclient just updated to 4.9.1-6
- libmount just updated to 2.23.2-61
- CIFS mount options: vers=3.0,credentials=/root/credentials.txt,sec=ntlmsspi
- File /root/credentials.txt contained a username and password that are LOCAL to the SMB server
Troubleshooting & solution
I was able to isolate the problem to mount.cifs with the following procedure:
- Mount the SMB share from a Windows host, using the same credentials as the Linux host. This proved that the credentials were valid and there were no problems on the SMB server side.
- Access the SMB share from the Linux host using smbclient. This step ruled out any network issues between the Linux and SMB server, and verified that the version of Samba installed on the Linux host was compatible with the SMB server.
I found the solution in a post from a couple of years ago in the askubuntu forum on StackExchange. It seems that one of the recent CentOS/RedHat updates changed some default behavior in the way that mount.cifs authenticates to SMB shares. When authenticating as a local user, you now have to specify the host as the domain. I did this by adding one line to the credentials file that is referenced from
/etc/fstab as shown below:
//188.8.131.52/share_name /mnt/mountpoint cifs vers=3.0,credentials=/root/credentials.txt,sec=ntlmsspi
Here are the contents of file
username=my_username password=my_password domain=184.108.40.206
I am not sure why this problem showed up now; it seems like it should have occurred months ago when we updated to latest version of cifs-utils. I’m also unsure if this problem will occur if you’re attempting to authenticate as a domain user. Let me know in the comments!