10

I'm trying to mount a NetApp CIFS share to one of our servers and I keep getting "Permission Denied" printed to stderr and NT_STATUS_WRONG_PASSWORD printed to the running dmesg. 

root@xxxehpvld05 ~ $ mount.cifs -vv //zhp-nas.xxx.com/perspectives /mnt/secure/cifs -o credentials=/etc/cifs.creds
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
root@xxxehpvld05 ~ $ dmesg | tail
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13

The smbclient command, however works without issue, using the same exact credentials file:

root@xxxehpvld05 ~ $ smbclient -L //zhp-nas.xxx.com/perspectives -A /etc/cifs.creds
Domain=[XXX] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]

        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       Remote IPC
        ZHPSubmit-dev   Disk
    [...snip...]

It seems like if one works the other should as well especially since the credentials file also specifies the domain name.

| improve this question | |
  • what happened to the bounty? – user55518 Jul 24 '14 at 22:32
  • Never got an answer that worked for me so the bounty eventually expired and all those points went the way of the dodo. – Bratchley Jul 25 '14 at 1:34
  • If you can think of the answer, I'll award you a new bounty, I just don't want to keep forfeiting points if I don't get an answer. – Bratchley Jul 25 '14 at 12:52
  • So, I was having a similar issue (with the -13 error from kernel module). I installed cifs-utils package (Debian) and it resolved the issue. I spent a bit debugging this because I was not expecting any support without the package having been installed, so I assumed it was. I was expecting something like "unknown filesystem" from mount, but that didn't happen. – sherrellbc Jan 4 at 20:57
7

With out more info I can't say for sure but I have seen this issue when connecting to an older windows server that was running an older protocol version. Remember CIFS is considered a "Dialect" (type) of SMB. There are other types and older setups don't use CIFS.

Basically it's like saying two people are speaking. One Spanish and one English, and your trying to force the English speaker to understand Spanish when clearly he doesn't.

SMBclient uses a different dielect for security negotiations. (or at least detects differently).

Try

mount -t cifs //path/thing/ /mount/point -o username=user,password=pass,sec=ntlm

and see what happens. (sec=ntlm is the important part)

| improve this answer | |
  • Same issue even when specifying NTLM authentication. Same if I do ntlm or ntlmv2. I'm unsure of how to troubleshoot it so if you need more information let me know and I'll update the question. Could there be some access controls on the NetApp side that the SAN guy missed? – Bratchley Jun 30 '14 at 17:19
  • Version of the server software, are there any routers or switches in the way? – coteyr Jun 30 '14 at 18:37
  • Same subnet. Not sure what version of Samba is on the other side since it's a NetApp ONTAP appliance. – Bratchley Jul 2 '14 at 17:46
4

Playing around with the commands, I found a possible reason:

From the man page of smbclient:

   -A|--authentication-file=filename
       This option allows you to specify a file from which to read the
       username and password used in the connection. The format of the file is

           username = <value>
           password = <value>
           domain   = <value>

       Make certain that the permissions on the file restrict access from
       unwanted users.

From the man page of mount.cifs:

   credentials=filename
       specifies a file that contains a username and/or password and
       optionally the name of the workgroup. The format of the file is:

          username=value
          password=value
          domain=value

Then I created two credential files, one with spaces, as showed in the first snippet and one without and named them creds and creds.spacy.

The big showdown:

With creds file:

mount.cifs -vvv //host/path /local/path -o credentials=/path/creds

good silence, no errors.

With creds.spacy file:

# mount.cifs -vvv //host/path /local/path -o credentials=/path/creds.spacy
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

So obviously your credentials file contains spaces, which are not understood by mount.cifs.

In addition for smbclient it doesn't matter if there are spaces. creds and creds.spacy did not cause any grouse.

| improve this answer | |
  • There was an extra blank line at the end of the file but I get the same thing after deleting it. This is a slightly redacted version of what's in the creds file. Redacted and real passwords are mixed case passwords containing "!" as a special character. – Bratchley Jul 2 '14 at 17:50
  • There's another aspect to this, which this solution led me to find: The credentials must be in the correct order, i.e. username, password, domain and not any other order like domain, username, password (which is what I had). This also works fine with smbclient but fails for mount.cifs. Once I changed the order to the correct one as specified in the documentation you quoted here, it started working. Seems like these (both mishandling of spaces and the ordering issue) are terrible bugs that should be easily fixable by whoever maintains mount.cifs. – leftclickben Apr 8 '16 at 6:42
2

Adding sec=ntlm corrected the problem for me. I have an older NAS (netgear stora). The default security for cifs in recent kernels is ntlmssp

| improve this answer | |
  • Worked for me, too. I don't know the real cause yet. In case it helps someone: isilon mount on ubuntu LTS 14.04. The isilon (some SAN thingy) talks to our windows active directory. The same account worked like a charm on other machines and when directly mounting it in windows. – Reinout van Rees Apr 30 '15 at 8:23
  • Extra note: 12.04 with the latest updates works fine, 14.04 is somehow part of the problem now (late april 2015). – Reinout van Rees Apr 30 '15 at 10:37
  • Last extra note: the core issue was a known microsoft problem with emc isilon storage and update KB3002657 (or so my sysadmin tells me right now :-) ) – Reinout van Rees May 1 '15 at 12:10
2

Another possibility that I discovered while trying to mount a share today is that smbmount supports the username=DOMAIN\\user syntax to supply a user in a domain as the credential.

For mount.cifs (and mount -t cifs) to work, these two have to be provided separately: -o username=user,password=pass,dom=DOMAIN.

| improve this answer | |
  • To mount an smb 3.0 share served by a NetApp Clustered Data ONTAP had to call out both sec=ntlm and dom=DOMAIN – iii Sep 14 '15 at 21:50
1

As user55518 explained, you probably have spaces in your credentials file even if you don't see them. If you edited your credentials file on Windows, you probably have \r at the end of your lines and that throws the error 13.

| improve this answer | |
  • you can use the command set list in vim to check for extra tabs/spaces – vfbsilva Jun 27 '17 at 18:50
0

I want to thank all of u !!! for this issue, It really help me a lot!, also i found some important information about the parameter "sec=ntlm", so i leave the link if some of u are interesting about it, lines below :

Microsoft NTLM

I was trying to mount a share directory from windows 7 desktop, but i was impossible til add the parameter "sec=ntlm" and it works, and some important detail could be that i didn't consider that my windows 7 desktop was into a domain, so I think it was the most important detail that I should consider. therefore, It works!, really thank u very much all of u!, blessings!! and good vibes! :D

| improve this answer | |
0

In my case, I only needed to add the option vers=3.0 (CIFS was version 1, which is no longer supported since kernel 4.13, so I switched right to SMBv3 on the server) and still I had to reboot to make it work, this is my mount line in /etc/fstab now:

auto,rw,credentials=/usr/local/etc/smb.credentials,vers=3.0,file_mode=0664,dir_mode=0775,uid=myuser,gid=users

My credentials file:

username=myuser
password=****
domain=mydomain

Actually, domain is not needed, but it's the correct option to use according to the mount.cifs man page now.

| improve this answer | |
0

I have been struggling with this for a while.

With following errors:

mount error(112): Host is down

here it helped to set vers=1.0 option, then it reported

mount error(13): Permission denied

and it turned out to be extra " characters in my credentials file

where originally I had:

# cat /etc/samba/cred-file
username="john"
password="secret"

where it should be

# cat /etc/samba/cred-file
username=john
password=secret
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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