Cifs - mount error(13): Permission denied

Support Network
1

I’ve had an entry in my fstab that has been working well for a long time. However, upon a recent reboot that suddenly changed. It might be related to the latest cifs-utils update (Arch Linux - cifs-utils 6.13-2 (x86_64)). I’ve tried debugging but can’t figure out what the problem is. Any help is appreciated.

Accessing the file system using AFP works just fine:

AFP access:
afp://xylan.local/shared

Mounting with verbose output:

$ sudo mount -v -a
[sudo] password for poq: 
/boot/efi                : already mounted
/                        : ignored
/media/drive2            : already mounted
/media/drive3            : already mounted
mount.cifs kernel mount options: ip=192.168.1.41,unc=\\192.168.1.41\shared,iocharset=utf8,noperm,mfsymlinks,uid=1000,gid=1000,user=poqpoq,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Possibly related:

2

Samba is something quite to itself and cifs is the old - very old name for the first version but it is Samba nonetheless.

Samba is a reverse engineered proprietary Microsoft protocol suite with all the dysfunctionality that comes with that territory.

Don’t use uid-gid mapping it won’t work as samba is access/no access - and if you have access it is readonly or write access and this is controlled by a username password combo on the server providing the share.

When you are using fstab - something like this should do it

//192.168.1.41/shared cifs iocharset=utf8,rw,file_mode=0777,dir_mode=0777,user=$SMBUSER,password=$SMBPASS,workgroup=$WORKGROUP

Of course you will need to ensure your local username has access to the local mountpoint.

I do advocate the user of systemd mount units because of their flexibility and because it cuts out the middleman

1 Like
3

Thanks a lot for a great and constructive feedback. @linux-aarhus. The use of systemd mount units was news to me. It seems like a nice way of mounting. Wonderful tip!

Doing this, I still ran into problems though. journalctl -xe shows the following error:

May 22 18:25:02 tw kernel: CIFS: Attempting to mount \\192.168.1.41\shared
May 22 18:25:02 tw kernel: CIFS: VFS: Could not allocate crypto cmac(aes)
May 22 18:25:02 tw kernel: CIFS: VFS: Could not allocate crypto md4
May 22 18:25:02 tw mount[183603]: mount error(13): Permission denied

Is this a cifs issue, or a kernel issue? This started after upgrading to 5.11.19-1, so there might be a correlation.

4

I upgraded to kernel 5.12.2-1, and then everything worked just fine again. So, there seems to be some bug (?) in the latest 5.11.

Not sure if it’s related, however, it might be:

To me that suggests that CIFS (a kernel module) is lacking some crypto module, likely tcrypt.

mount.cifs error: CIFS VFS: could not allocate crypto hmacmd5 · Issue #149 · rear/rear · GitHub

Anyhow, I’m glad it works again. As well I’m now using “systemd mount unit”, thanks to @linux-aarhus. :smiley:

5

I must say I am in the dark with that one - see - I am using smb share on a daily base - I have never ran into this message.

Just throwing an idea - could this be due to inconsistencies in what SMB version the server provides vs. the version the client expect?

We have had a lot of issues when Samba deprected SMBv1 - it could be related - but I don’t know.

Do you have a file /etc/samba/smb.conf on the client side?

If not try creating a basic file with something like this in the global section (use a procotol setting suitable for your the server providing the share) [1]

[global]
    workgroup = WORKGROUP
    client min protocol = SMB2

Frankly - I don’t know - I have been on every kernel version - and as noted above - I have never encountered any issues - but if it works now - I am happy on your behalf - I am just not able to provide any explanation.

1 Like
6

Weird thing, this one. But I’m glad it works again as well. Maybe it was not related to the kernel upgrade, but something else that happened on the reboot? I’m scratching my bald head, while being able to mount my NAS.

Thanks a lot for very constructive feedback, @linux-aarhus!

7

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.