64

One of my servers is set up to automatically mount a Windows directory using fstab. However, after my last reboot it stopped working. The line in fstab is:

//myserver/myfolder /mnt/backup cifs credentials=home/myfolder/.Smbcredentials

The .Smbcredentials file is:

username=myaccount
password=mypassword
domain=mydomain

I do a mount -a and I receive mount error 13 = Permission denied. If I do this enough it will lock out my Windows account, so I know it's trying. I've checked that my password is correct.

What am i doing wrong?

phemmer
  • 70,657
  • 19
  • 188
  • 223
Pickle
  • 1,041
  • 1
  • 8
  • 7
  • 4
    Could you try mount from the command line with `mount -t cifs //myserver/myfolder /mnt/backup --verbose -o credentials=home/myfolder/.Smbcredentials` and add the debugging info (sanitized) to your question? – bsd Apr 11 '14 at 20:44
  • What's the distro and version of `cifs-utils` do you have installed? I've had this problem before and I believe it was due to an update. – slm Apr 11 '14 at 22:37
  • this error most likely connects to `NT_STATUS_LOGON_FAILURE` which you can see them in `dmesg`. I assume that the username and password were correct. Please make sure that the credential file using LINUX (LF -- \n) instead of WINDOWS (CRLF -- \r\n). – ZenithS Aug 26 '22 at 05:29

5 Answers5

64

A couple of things to check out. I do something similar and you can test mount it directly using the mount command to make sure you have things setup right.

Permissions on credentials file

Make sure that this file is permissioned right.

$ sudo ls -l /etc/smb_credentials.txt 
-rw-------. 1 root root 54 Mar 24 13:19 /etc/smb_credentials.txt

Verbose mount

You can coax more info out of mount using the -v switch which will often times show you where things are getting tripped up.

$ sudo mount -v -t cifs //server/share /mnt \
    -o credentials=/etc/smb_credentials.txt

Resulting in this output if it works:

mount.cifs kernel mount options: ip=192.168.1.14,unc=\\server\share,credentials=/etc/smb_credentials.txt,ver=1,user=someuser,domain=somedom,pass=********

Check the logs

After running the above mount command take a look inside your dmesg and /var/log/messages or /var/log/syslog files for any error messages that may have been generated when you attempted the mount.

Type of security

You can pass a lot of extra options via the -o .. switch to mount. These options are technology specific, so in your case they're applicable to mount.cifs specifically. Take a look at the mount.cifs man page for more on all the options you can pass.

I would suspect you're missing an option to sec=.... Specifically one of these options:

   sec=
       Security mode. Allowed values are:
       ·   none - attempt to connection as a null user (no name)
       ·   krb5 - Use Kerberos version 5 authentication
       ·   krb5i - Use Kerberos authentication and forcibly enable packet 
           signing
       ·   ntlm - Use NTLM password hashing
       ·   ntlmi - Use NTLM password hashing and force packet signing
       ·   ntlmv2 - Use NTLMv2 password hashing
       ·   ntlmv2i - Use NTLMv2 password hashing and force packet signing
       ·   ntlmssp - Use NTLMv2 password hashing encapsulated in Raw NTLMSSP
           message
       ·   ntlmsspi - Use NTLMv2 password hashing encapsulated in Raw 
           NTLMSSP message, and force packet signing

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

You may need to adjust the sec=... option so that it's either sec=ntlm or sec=ntlmssp.

References

slm
  • 363,520
  • 117
  • 767
  • 871
  • 2
    Checking `dmesg` was very helpful. This answer was from 2014, and since then, the WannaCry exploitation of SMB1.0 has made it deprecated, so be sure to add `vers=2.0` or 2.1 or 3.0, whatever the server supports, as the default 1.0 will no longer be supported. – Michael Plautz Oct 15 '18 at 19:36
  • 1
    Just a heads-up: since the destination folder is under Windows, which often requires the change of password every once in a while, the password in the credential file may be invalid. `mount` command will not tell you such details. – HongboZhu Sep 10 '19 at 13:35
  • 2
    I had to specify `sec=ntlm` to mount a Synology share, thanks a lot! – Panki Nov 27 '19 at 11:21
  • My colleague and me suck with this for 1.5 hours. I gave all my credentials to him, and he set something on server side, so don't forget to mention that there could be security problems on server side too. – vaso123 Apr 19 '21 at 06:59
  • 1
    `-v` option was the saviour for me, in the credentials file I had misspelt `username` as `usename` and so the resulting string was setting the user string as blank. Small typos really are a pain. – Hansang Mar 13 '23 at 04:32
30

Thanks, but some more googling turned up the solution. It was using the wrong security type by default; this command worked:

$ sudo mount -t cifs //172.16.1.5/myshare/ /mnt/myshare \
    -osec=ntlmv2,domain=MYDOMAIN,username=myusername,password=mypassword
slm
  • 363,520
  • 117
  • 767
  • 871
Pickle
  • 1,041
  • 1
  • 8
  • 7
  • This was it! Running `mount -t cifs //10.0.0.138/usb1_1 /mnt/usbdisk -ousername=theusername,password=thepassord,file_mode=0644,dir_mode=0755,uid=root` on a Fedora 25 machine worked fine, but failed when I ran the exact same command on an openwrt box (Chaos Calmer 15.05.1). Adding `sec=ntlmv2` made it work there as well. – hlovdal Feb 11 '17 at 18:09
  • 3
    Came here trying to mount a Debian 9 AD member from a CentOS 6 non-member, and this got me close -- for my case the magic was `sec=ntlmssp` – Cheetah Apr 13 '18 at 22:43
  • 1
    The fix for me was to use the `domain` keyword and specify it apart from the username. – Jim Fell Feb 12 '19 at 19:08
  • sec=ntlmv2 has the option I just needed for my smb access from Ubuntu 18.04 to Windows 10 share. Thanks, Pickle. – noel aye Mar 10 '19 at 13:07
  • its quit simple you need to escape your password with> ' sudo mount -t cifs //172.16.1.5/myshare/ /mnt/myshare -o username=myusername,password='mypassword' – Masood Moshref Apr 24 '20 at 19:35
15

I ran into this problem and the issue turned out to be not formatting the values in my credentials file correctly. I tried:

username=DOMAIN\mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

I also tried:

[email protected]
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

And:

username=FULLY.QUALIFIED.DOMAIN\mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

Once I just used my login username only:

username=mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

I was able to get my cifs mount to succeed.

Mark Salisbury
  • 151
  • 1
  • 2
3

This add works on scientific Linux 6.6 (RedHat 6.6)

edit /etc/fstab
create file = .credentials (e.g. in /etc ) with this details :

username=value
password=value
domain=value

//SERVER/SHARE1 /mnt/SHARE1 cifs credentials=/etc/.credentials,rw,uid=1000,gid=1000,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0
Community
  • 1
stoferontheweb
  • 31
  • 2
1

For an AD environment, I have to leave and rejoin the domain.

net ads leave -U domain-admin-username

kinit domain-admin-username
net ads join -U domain-admin-username
systemctl restart smbd nmbd winbind

Not sure why this was necessary, but happened after a routine reboot for updates. There were no other indications of any AD related issues while receiving this error.

Louis Waweru
  • 175
  • 1
  • 8