I wanted to get my head around this and started investigating it and see what was the problem, be it the way I am doing it, or the way the samba server is configured.
With a few searches I kind of checked that the server side was ok, and configured in a simple way and should not be an issue.
So I started to focus more on the "client" which is the Kubuntu desktop I am using for my day to day stuff.
I have been manually mounting the share I need when I boot the desktop and as the desktop stays always on there is no need to worry much. But I wanted this to be done automatically, at boot, so I started to look how to do it.
After some tries along the way as I moved to a linux desktop last year, I had a very simple command line:
# sudo mount -t cifs -o uid=john,username=john,password=MySecurePass123 //192.168.1.100/data /mnt/data
# This worked perfectly, but it took a bit of time to get here to figure out the correct options for the mount to work. username and password are related to the samba share, that have been configured in the samba server.
Initially I was using just like that, and the mounts were being mounted but only read only, but after some searches in found out that I needed an extra parameter/option that "linked" the samba server username to the Linux username I was using.
That is the option uid that is just mapping the local Linux user to the username from the samba server. And this worked fine.
Of course it is not a safe way of doing this, the password needs to be type on the command line. So I started looking onto how to do this in a more secure way, and the advice I found was all around using a credentials file instead.
From several places the correct Credentials File Format is like this:
- No quotes around `username` or `password`.
- No trailing white space or newlines.
- No special characters or encoding issues (e.g., UTF-8 BOM).
- credentials file must be readable only by you.
A bad credentials file (`~/.smbcred`) might look like this:
# cat ~smbcred
username="john"
password="MySecurePass123"
# Notice the quotes and possible hidden characters
A good one should be like this:
# cat ~/smbcred
username=john
password=MySecurePass123
# cat -A ~/smbcred
username=john\$
password=MySecurePass123\$
# The second cat command with the -A option is to show all characters and in this case the "$" is the end of line.
With the file correctly formatted I issued the command with the credentials file:
# sudo mount -t cifs -o uid=john,credentials=/home/john/.smbcred //192.168.1.100/data /mnt/data
mount: /mnt/data: cannot mount //192.168.1.100/data read-only.
dmesg(1) may have more information after failed mount system call.
# dmesg
[1401186.991368] CIFS: Attempting to mount //192.168.1.100/data
[1401187.003059] CIFS: VFS: cifs_mount failed w/return code = -13
# As you can see, it fails with the message above, and after issuing "dmesg", the -13 code means "Permission denied".
The interesting bit here was the if I issued the command where all the information is typed on the command line it worked without any problems.
So, why does this happen?
This was a lot of head scratching has I couldn't make sense of what was happening.
I started searching the internet as a first option, and apart from the advice to make sure that the credentials file was in the correct format and with the correct permissions I came nowhere.
So then I decided to give a go with the different AI tools, started with ChatGPT, Claude and finally Gemini.
I have used the same prompt for all of them, and they went through the same actions to check the credentials file, the permissions.
Every error, kind always the same, I would paste it in the prompt and similar answers from all the three AI tools.
But after a few attempts. Gemini came with a new suggestion to check, based on what it stated that the mount command needs the mount.cifs helper program.
In many Linux distributions, the standard mount command **cannot parse a `credentials=` file on its own**, It relies on a helper program called **`mount.cifs`** (from the `cifs-utils` package) to handle SMB/CIFS mounts.
So Gemini stated that either the mount.cifs command is missing or is not being triggered, which means the credentials file is not read correctly and fails authentication and gives you a "Permission denied"
A quick check on my desktop immediately showed that mount.cifs command was not present. The mount.cifs command is part of the cits-utils package that handles the SBM/CIFS mounts.
Another quick check also showed the the cifs-utils was not installed, then I just needed to:
# sudo apt install cifs-utils
Installing:
cifs-utils
...
...
Setting up cifs-utils (2:7.4-1) ...
# With the cifs-utils package installed, I attempted again the mount and this time it worked like charm.
I am not suggesting with this that Gemini is better than the others, just maybe I insisted more with it.
One of the suggestions that all the searches and AI tools referred to was to use fstab to mount the shares, so I don't depend on manual mounts.
I went ahead and done just that.
I should use `/etc/fstab` for persistent mounts
For this I just needed to add the following line to the fstad:
//192.168.1.100/data /mnt/data cifs uid=john,credentials=/home/john/.smbcred,rw 0 0
And I could issue the command in my running desktop to check it worked:
# sudo mount -a
# Then a final test done by rebooting the machine and check if the mount point was in place, and it was.