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
4
  • what happened to the bounty? Commented Jul 24, 2014 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. Commented Jul 25, 2014 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. Commented Jul 25, 2014 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. Commented Jan 4, 2020 at 20:57

8 Answers 8

Reset to default
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
3
  • 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? Commented Jun 30, 2014 at 17:19
  • Version of the server software, are there any routers or switches in the way? Commented Jun 30, 2014 at 18:37
  • Same subnet. Not sure what version of Samba is on the other side since it's a NetApp ONTAP appliance. Commented Jul 2, 2014 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
2
  • 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. Commented Jul 2, 2014 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. Commented Apr 8, 2016 at 6:42
3

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
2
  • To mount an smb 3.0 share served by a NetApp Clustered Data ONTAP had to call out both sec=ntlm and dom=DOMAIN Commented Sep 14, 2015 at 21:50
  • this was the solution when connecting to a windows share on a domain. smbclient is able to use the username like user@domain while mount needs in the format shown by fiskfisk Commented Sep 8, 2021 at 6:49
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
3
  • 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. Commented Apr 30, 2015 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). Commented Apr 30, 2015 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 :-) ) Commented May 1, 2015 at 12:10
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
1
  • you can use the command set list in vim to check for extra tabs/spaces Commented Jun 27, 2017 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
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

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.