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:


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?

  • 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

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=,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:

       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 
       ·   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
       ·   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.


  • 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 at 6:59

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 // /mnt/myshare \
  • This was it! Running mount -t cifs // /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
  • 2
    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
  • 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 // /mnt/myshare -o username=myusername,password='mypassword' – Masood Moshref Apr 24 '20 at 19:35

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


I also tried:




Once I just used my login username only:


I was able to get my cifs mount to succeed.

  • great explanation! – Dima Lituiev Jul 21 '17 at 22:09
  • FULLY.QUALIFIED.DOMAIN did it for me, after struggling for an hour! Thanks! You can read your fully qualified domain with $ hostname -f. – alex.dev Dec 22 '20 at 10:10
  • I'm pretty sure this was my problem too. I had created the credentials file from Windows and the line endings (EOL) were Windows. When I changed them to Unix it worked. – FlexMcMurphy Mar 14 at 19:41

This add works on scientific Linux 6.6 (RedHat 6.6)

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


//SERVER/SHARE1 /mnt/SHARE1 cifs credentials=/etc/.credentials,rw,uid=1000,gid=1000,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0 
  • file_mode and dir_mode flags solved for me! :) – Rafael Moni Jan 10 '19 at 13:45

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.