SMB mount Security Modes and Fixing mount error(13): Permission denied in Linux

1. Introduction

The mount command is a way to attach remote filesystems as local filesystem paths. Yet, most external systems like those that employ Server Message Block (SMB) as the Common Internet File System (CIFS) or Samba require authentication for resource access. Thus, mount provides parameters to facilitate this interaction securely.

In this tutorial, we understand some of the main security parameters of the mount command, reasons for the Permission denied error (13) when mounting, and solutions to the error. First, we briefly refresh our knowledge about authentication during mounting. Next, we turn to SMB as the specific protocol that usually causes the Permission denied error unexpectedly and go over some basic troubleshooting. Finally, we explore advanced client and server SMB options for troubleshooting and fixing misconfigured environments.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. Unless otherwise specified, it should work in most POSIX-compliant environments.

2. Mount Authentication

Since mounting remote filesystems requires access to the host, mount should provide a way to authenticate itself when establishing a connection.

Depending on the protocol in use, authentication can come down to many aspects of the session:

• Secure Shell (SSH): establish a secure tunnel before attempting a mount to allow access through that tunnel
• Network File System (NFS): configure an NFS server to allow access to a given client based on certain characteristics
• Server Message Block (SMB) as the Common Internet File System (CIFS) or Samba: supply a username and password combination

Regardless of the method of choice, we might encounter an error that states permissions are denied.

However, in some cases, the mount command itself can produce a specific error:

$ mount //192.168.6.66/smb/ /mnt/smb/
mount error(13): Permission denied

In this instance, the culprit is usually an SMB mount.

3. Basic SMB Authentication Issues and Resolutions

There can be different reasons for the mount error(13): Permission denied error when mounting an SMB share with different options.

Notably, this error isn’t related to the owner of the mount or the internal mount rights once the mount command succeeds.

3.1. Incorrect Server or Path

Despite its triviality, a wrong server reference or a typographical error in the otherwise correct hostname can lead to a permissions issue:

$ mount //192.168.6.6/smb/ /mnt/smb/
mount error(13): Permission denied
$ mount //192.168.6.66/smb/ /mnt/smb/
$

This is especially true for sequential or similar names and addresses.

Thus, checking whether the full share path is as expected should always be one of the first troubleshooting steps.

3.2. Incorrect SMB Server Configuration

Of course, even if we specify the correct server, the SMB settings or general configuration might not allow the authentication attempt.

For instance, /etc/samba/smb.conf should expose the available views and shares. However, the configuration might also include options like valid users and invalid users that can restrict access to the user mount is using:

$ mount --options user=invalid //192.168.6.66/smb/ /mnt/smb/
mount error(13): Permission denied
$ mount --options user=valid //192.168.6.66/smb/ /mnt/smb/
$

So, verifying the server configuration, especially in terms of security, can be crucial.

3.3. Incorrect User or Password

On the other hand, apart from being misconfigured on the server side, the user and password themselves can be the wrong ones or simply mistyped:

$ mount --options user=usr1,password=PASSWORD //192.168.6.66/smb/ /mnt/smb/
mount error(13): Permission denied
$ mount --options user=user1,password=PASSWORD //192.168.6.66/smb/ /mnt/smb/
$

Similar to the server hostname and address, double-checking the credentials is paramount.

4. Advanced SMB Security Mode Settings and Solutions

Lastly, we discuss a session parameter related to the server configuration that is still easy to misalign on the client side: the security mode. The latter is negotiated based on a number of implicit and explicit restrictions.

In general, finding the NTLM protocol suite or Kerberos version of a server and ensuring the client uses the same can be non-trivial, but is critical for the proper communication.

4.1. Client sec Option of mount

The sec option of the mount command has a higher precedence to other SMB client settings and should be the same as the security mode on the server side.

In particular, the value of sec is often implicit on the client side, yet it’s vital to the way security is handled:

• none: attempt to connect as a user without a name
• krb5: Kerberos version 5
• krb5i: Kerberos version 5 and forced packet signing
• ntlm: use basic NTLMv1 password hashing
• ntlmi: NTLMv1 password hashing and forced packet signing
• ntlmv2: NTLMv2 password hashing
• ntlmv2i: NTLMv2 password hashing and forced packet signing
• ntlmssp: NTLMv2 password hashing with raw NTLMSSP encapsulation
• ntlmsspi: NTLMv2 password hashing with raw NTLMSSP encapsulation and forced packet signing

In the mainline Linux kernel, the default was sec = ntlm in versions before 3.8. After version 3.8, the default is sec = ntlmssp. Yet, different servers require ntlm, ntlmv2, or even ntlmssp.

Depending on the context and command, this can cause a mount error(22): Invalid argument error, but it can also lead to the mount error(13): Permission denied error.

4.2. Client Options

On the client side, apart from the mount options and /proc, SMB provides several other global settings in local client smb.conf file:

• client lanman auth (default no): LANMAN password hashing (deprecated)
• client ntlmv2 auth (default yes): NTLMv2 password hashing, disables earlier algorithms
• client signing (default default): client signing with auto (default) allowing but not enforcing, mandatory enforcing, and disabled disallowing the option

Thus, the client can control the security mode.

4.3. Server Options

On the server side, this usually comes down to checking the registry settings on Microsoft Windows or the /etc/samba/smb.conf configuration file in Linux.

The latter can have a value set for several options.

To begin with, LANMAN password hashing can be controlled via lanman auth:

• lanman auth = yes: allow LANMAN and NTLMv1 authentication
• lanman auth = disabled: disallow LANMAN and NTLMv1 authentication
• lanman auth = no (default): permanently prevents LANMAN from working, even when reenabled later

On the other hand, the ntlm auth option exposes the main security mechanism:

• ntlm auth = ntlmv1-permitted, ntlm auth = yes (default before Samba version 4.5): allow NTLMv1 and above
• ntlm auth = ntlmv2-only (default in Samba versions 4.7 and above), ntlm auth = no (default in Samba versions 4.5 to 4.7): disallow NTLMv1, allow NTLMv2
• ntlm auth = mschapv2-and-ntlmv2-only: allow NTLMv1 with MSCHAPv2 authentication
• ntlm auth = disabled: disallow NTLM and LANMAN(deprecated) authentication

Notably, these options only pertain to local users, not any domain.

Further, raw ntlmv2 auth can allow (yes) or disallow (no, default) SMBv1 clients without SPNEGO extended security to use NTLMv2.

Lastly, the server signing decides if clients are allowed or required to employ SMBv1 and SMBv2 signing:

• server signing = default (default): signing required when an Active Directory controller
• server signing = auto: signing allowed, but not required
• server signing = mandatory: signing required
• server signing = disabled: signing disallowed

In SMBv2, the value is always treated as mandatory.

Since there are many options, let’s break down some key combinations.

4.4. Server and Client Option Combinations

In the most common case, we only want NTLMv2:

$ cat smb.conf
[global]
  lanman auth = disabled
  ntlm auth = no
[...]

Again, no here is an alias for ntlmv2-only. Many clients may not support NTLMv2, which may necessitate client changes or upgrades.

Importantly, to force NTLMv2 only within NTLMSSP, we can disable all other methods:

$ cat /etc/samba/smb.conf
[global]
  raw ntlmv2 auth = no
  lanman auth = disabled
  ntlm auth = no
[...]

Here, sec=ntlmssp may be required as an option to the client mount command itself.

In the case of very old clients, we can turn on LANMAN and NTLMv1, but this isn’t recommended:

$ cat /etc/samba/smb.conf
[global]
  lanman auth = yes
  ntlm auth = yes
[...]

For a bit more security, we can disable LANMAN:

$ cat /etc/samba/smb.conf
[global]
  lanman auth = no
  ntlm auth = yes
  client lanman auth = no
[...]

Notably, if NTLMv2 clients are unable to authenticate with NTLMv1 enabled, we change the client-side settings to force NTLMv2:

$ cat $HOME/.smb/smb.conf
[global]
  sec = ntlmv2
  client ntlmv2 auth = yes
[...]

Again, the sec option to mount can be modified appropriately.

5. Summary

In this article, we discussed the mount command, its security modes related to the SMB protocol, an unexpected error that mismatches can produce, and the implications of different settings.

In conclusion, as a common way to share data between different Linux and non-Linux environments, understanding how mount behaves with SMB security modes and configurations along with ways to troubleshoot related issues can be critical.