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)
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
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: 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.
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) 
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.
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.