mount error(13): Permission denied

Question

I know this question has been asked before, but I've been looking for a solution for a couple of hours now and nothing seems to be working.

The frustrating thing is that it used to work on my previous install, so I know the commands I try should work.

I'm running a vanilla install of Ubuntu 13.04 server.

I have a server running at 192.168.1.130 and two shares: LaCie and Seagate 2TB.

I used to have these lines in my fstab file:

//192.168.1.130/Seagate\0402TB /home/Windows cifs user=admin,password=password,uid=1000 0 0

Now that I re-installed my server, but don't need it permanently I tried the following:

sudo mount.cifs //192.168.1.130/LaCie ~/lacie -o user=admin

or

sudo mount -t cifs -o username='admin',password='<password>' //192.168.1.130/LaCie ~/lacie

However, I get the error mount error(13): Permission denied.

I'm sure the credentials are correct. Nothing has changed at the windows side.

Also, I installed the packages samba, cifs-utils too. Nothing helped.

Solution 1

//192.168.1.130/seagate /home/seagate cifs username=administrator,password=<pwd>,uid=1000 0 0 

This solved the problem! (i.e., leave the quotation marks out!)

Solution 2

i had this same error. what solved it for me is reverting mount.cifs's security parameter back to its previous default as indicated here and in mount.cifs' manpage:

The default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8, the default was changed to sec=ntlmssp.

in your case, the new command would be

sudo mount.cifs //192.168.1.130/LaCie ~/lacie -o user=admin,sec=ntlm

notice sec=ntlm at the end

Solution 3

In my case, it turned out to be time issues on the Windows machine - it has some problem where its time lags severely, in the range of 2 days per week (most likely the motherboard battery needs replacing). I manually updated the time and mount succeeded.

Arch Linux machine connecting to a Windows XP one, but I'd suspect it would be a problem for Ubuntu to newer Windowses as well.

Solution 4

I had this issue as well. I'm using centos (rpm based). I was getting mount error(13): Permission denied as well. Then I discovered that the problem was caused by SELinux (the lack of public_content_t context type) and of course the samba user smbpasswd -a <user> should have ownership of the directory.

• semanage fcontext -a -t public_content_t "/mydir(/.*)?" - adding public_content_t, verify using ls -lZ. Alternatively, turn off the selinux - setenforce 0 (runtime), edit either /etc/sysconfig/selinux or /etc/selinux/config by adding/altering SELINUX=disabled (permanently)
• chown :user1 /mydir && chmod +0070 /mydir - giving an access for group, the member of which the samba user is.

Solution 5

I am using Ubuntu 14.04.1 LTS after upgrading and had the same problem

What I did to immediately remap the network folder was:

mount -t cifs //Server/Folder/ /mnt/MapedFolder -o domain=contoso.local,username=user,password=pass,sec=ntlm

Hope it helps others

View more solutions

Comments

[Alaa Ali]

Can you try user=admin instead of username=admin, and without the ' apostrophe? Also, can you add the user option too? So sudo mount -t cifs -o user,user=admin,password=password //192.168.1.130/LaCie ~/lacie.

[Dan6073]

Also, does this work if you prefix the command with sudo?

[Jonathan Hagen]

Allright, I've got the following command to work, but in /etc/fstab it's still nothing :( sudo mount -t cifs -o username='administrator',password='<pwd>' //192.168.1.130/seagate /home/seagate

[Jonathan Hagen]

//192.168.1.130/seagate /home/seagate cifs username=administrator,password=<pwd>,uid=1000 0 0 this solved the problem! (ie leave the quotation marks out!)

[Alaa Ali]

Hi @ChristopheDeTroyer! Can you please post this as an answer to the question? You can answer your own question; in fact, it is encouraged to do so.

[Benoit Duffez]

Actually using ntlmssp solved it for me, as my default was already ntlm. Thanks a lot!

[Octopus]

The important missing param for me was sec=ntlm from an ARM running lubuntu, which I didnt need from a Fedora Desktop on x64

[mcmlxxxvi]

This wasn't the problem in my case, but it pointed me to the real one - time lag on my Windows machine as described in my answer. +1 and thanks.