Cifs vfs smb signature verification returned error 13

This document (000020670) is provided subject to the disclaimer at the end of this document.

This document (000020670) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 12 Service Pack 5
NetApp ONTAP 9.5p13

Situation

The kernel reports signature verification errors for cifs mounted shares like:

Mar 10 09:00:00 server kernel: [7107816.561996] CIFS VFS: \remotehostexportshare SMB signature verification returned error = -13
Mar 10 09:00:00 server kernel: [7107816.580025] CIFS VFS: sign fail cmd 0x8 message id 0x1507e
Mar 10 09:00:00 server kernel: [7107816.586944] CIFS VFS: \remotehostexportshare SMB signature verification returned error = -13
Mar 10 09:00:00 server kernel: [7107816.597301] CIFS VFS: sign fail cmd 0x8 message id 0x15082

These cifs shares are hosted on a NetApp filer running ONTAP 9.5p13.

Resolution

Please update to ONTAP 9.5p14. For further information please contact NetApp support.

Cause

The kernel module cifs.ko received a signature from the originating server that did not meet the requirements of the MS-SMB2 protocol («3.1.4.3 Encrypting the Message»).

Additional Information

Originally this issue was encountered using a SLES 12 SP5 based system but may be seen with other SUSE Linux Enterprise products connected to a NetApp storage running the mentioned ONTAP version.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented «AS IS» WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000020670
  • Creation Date:
    10-Jun-2022
  • Modified Date:10-Jun-2022
    • SUSE Linux Enterprise Server
    • SUSE Linux Enterprise Server for SAP Applications

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

Источник

Содержание

  1. systemd + cifs
  2. Host Volumes Stop Working with CIFS VFS: SMB signature verification returned error = -13 #3517
  3. Comments
  4. Expected behavior
  5. Actual behavior
  6. Information
  7. Thread: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13
  8. 20.04 mount cifs with password file: cifs_mount failed w/return code = -13
  9. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13
  10. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13
  11. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13
  12. mount.cifs error 13 after update (CentOS/RedHat Linux 7.6)
  13. Configuration that triggered the problem
  14. Troubleshooting & solution
  15. Unable to mount CIFS share on Linux: mount error(13): Permission denied (cifs_mount failed w/return code = -13)
  16. Add a comment
  17. Comments (newest first)
  18. Blog Tags:

systemd + cifs

Мой основной компьютер — mac и на нем настроена сетевая шара. В роли клиентов выстапают raspberry pi по квартире, на них установлен ArchLinux.
Недавно заметил что в логи постоянно сыпяться ошибки:

Ничего нагуглить толкового не получилось.

We have a CIFS mount which currently appears to be working as expected, but we see the following error constantly:

If a security flavor which does not require SMB signing is being used, then disable SMB signing at the server with the RequireSecuritySignature and EnableSecuritySignature REG_DWORDs as described in KB887429. Unmount and remount the CIFS client after this change, so that the connection is re-negotiated.

The krb5i, ntlmsspi, ntlmi, and ntlmv2i security flavors all require SMB signing to be enabled, so this workaround is not applicable if those flavors are in use.

This message relates to SMB signing, described by Microsoft at:

The server is supposed to send a signature when we mount, then also send a secondary signature in each SMB operation, where the secondary signature is derived from the server signature plus the contents of the SMB operation. This way a client is able to verify that a SMB operation arrived unmodified from the server.

For some reason, that signature verification is failing.

Источник

Host Volumes Stop Working with CIFS VFS: SMB signature verification returned error = -13 #3517

  • Windows Version: 10.0.17134 Build 17134
  • Docker for Windows Version: 2.0.0.3 (31259) Engine: 18.09.2
  • [x ] I have tried with the latest version of my channel (Stable or Edge)

Expected behavior

Containers would not lose connectivity to the host file system

Actual behavior

Containers randomly lose connectivity to the host file system

Information

I (and each of the other members of my team) are having the same problem that is described here:
https://github.com/docker/for-win/issues/2556

Periodically, our containers will lose connectivity to the host file system. This will last for about 1-3 minutes, before it resolves itself and reconnects.

Example of the container:

The logs at the time of the outage contain:

The problem isn’t reproducible; other than by running containers for prolonged periods of time and waiting for an outage. We have only recently started using docker for windows, and have been experiencing this issue right from the get-go.

Please let me know if anyone has any suggestions for ways we might work around this problem, or ways that we may go about debugging it!

The text was updated successfully, but these errors were encountered:

Also encountering this issue. I have noticed that just before the CIFS VFS: SMB signature verification returned error = -13 messages begin appearing in the log, Event ID 4634 (An account was logged off.) can be seen in the Windows Event Viewer.

After about 2 minutes the issue resolves itself and a CIFS VFS: Free previous auth_key.response = . message can be seen in the log (similar to @warrenspe’s log). Just before this log entry appears, I can see Events 4672 (Special Logon), 4624 (Logon), and 5140 (File Share) appear in the Windows Event Viewer, indicating that the share has been reconnected.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

Bit of extra information here; it happened again for me today and while it was in a bad state I was able to open my docker settings and reset the credentials on my shared drives. This has had the effect of making me unable to re-share the drives. When I check the share-box next to my C drive then enter my user credentials to authorize the share, the program processes for a moment, then unchecks the box.

It required restarting the docker service to be able to re-share the drive

The following was logged to the docker logs:

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

Источник

Thread: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

Thread Tools
Display

20.04 mount cifs with password file: cifs_mount failed w/return code = -13

I have two 20.04 machines, while host A has a samba share which I want to mount on host B using cifs with password file (for use in fstab)

When I use clear text credentials in the mount-command it works:

Then I created a file .smbcredentials owned by root with 600 permissions (I double checked theres no hidden spaces or blank lines in that file. I don’t have a windows domain, so theres no third line for domain, however I already tested with the line domain=WORKGROUP at the bottom of the file):

Since both machines are the same 20.04 with latest updates I don’t see a reason for a difference in used SMB versions, however, I verified all possible versions are supported (I also tried option vers=3.11 and all others until 2.02):

Since everything works when I type the credentials in the mount command, there’s no issue with the credentials itself and no issue with the permission structure on the Host A with the share. Windows machines have no issues using this share.

Any ideas or hints to check?

Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

Mount requires sudo in this situation.

This assumes the SHARE is correct and the /var/MOUNTPOINT exists. BTW, mounting CIFS storage under /var is unlikely to be a good idea. Probably best to mount it under /media. That will allow snap packages to have a chance to access it. /var expects Unix file systems, not CIFS.

Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

sorry, I forgot to mention, I did all my testings as root

anyway I gave it a try to mount in /media/testmount > same error

Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

This may sound dumb on my part, but I assume that package cifs-utils is installed right? It being missing is sometimes the culprit when trying to use a credential file.

Also the format of the credential file, if it is saved as UTF-8, then if it has UTF-8 BOM encoding characters at the start of that file (0xEF, 0xBB, 0xBF).

One other thing looking at the manpages, the format is

That may not matter, but just how I saw that. I know Morpheus had to help me with that about 11 years ago when it was driving me crazy trying to figure out what was wrong with one of my NAS mounts. I know how frustrating that can be.

EDIT:
The curious thing about that error return code, I looked it up in the Microsoft CIFS Docs, and I don’t see -13 as a return code that I can find in any of the tables.
https://docs.microsoft.com/en-us/ope. 6-f00569e3e1bc
Now that has me searching for it further.

EDIT2:
I found it in the RedHat CIFS Docs, returns a «-13» after this error:

Look at your Credential File for extraneous characters.

Last edited by MAFoElffen; January 11th, 2022 at 12:20 PM . Reason: Had to add spaces in an example or the Forums software was interpreting it as something different(?)

Источник

mount.cifs error 13 after update (CentOS/RedHat Linux 7.6)

If you recently updated your RedHat or CentOS 7.6 system, you may suddenly start getting “Permission Denied” errors when attempting to mount SMB shares via CIFS. Typical error messages in syslog look like this:

Configuration that triggered the problem

  • Synology NAS with latest operating system shares a volume via SMB
  • CentOS 7 Linux server mounts SMB share using a local username and password (NOT domain credentials)
  • cifs-utils version 6.2 installed in May of 2019 (this by itself worked fine)
  • libsmbclient just updated to 4.9.1-6
  • libmount just updated to 2.23.2-61
  • CIFS mount options: vers=3.0,credentials=/root/credentials.txt,sec=ntlmsspi
  • File /root/credentials.txt contained a username and password that are LOCAL to the SMB server

Troubleshooting & solution

I was able to isolate the problem to mount.cifs with the following procedure:

  1. Mount the SMB share from a Windows host, using the same credentials as the Linux host. This proved that the credentials were valid and there were no problems on the SMB server side.
  2. Access the SMB share from the Linux host using smbclient. This step ruled out any network issues between the Linux and SMB server, and verified that the version of Samba installed on the Linux host was compatible with the SMB server.

I found the solution in a post from a couple of years ago in the askubuntu forum on StackExchange. It seems that one of the recent CentOS/RedHat updates changed some default behavior in the way that mount.cifs authenticates to SMB shares. When authenticating as a local user, you now have to specify the host as the domain. I did this by adding one line to the credentials file that is referenced from /etc/fstab as shown below:

Here are the contents of file /root/credentials.txt :

I am not sure why this problem showed up now; it seems like it should have occurred months ago when we updated to latest version of cifs-utils. I’m also unsure if this problem will occur if you’re attempting to authenticate as a domain user. Let me know in the comments!

Источник

Published on January 4th 2022 — Listed in Linux Windows Samba

There are a couple of ways how to mount a CIFS/Samba share on a Linux client. However some tutorials are outdated and meanwhile completely wrong. I just ran into a (stupid) case of a wrong mount.cifs syntax:

# mount -t cifs //server/Share /mnt -o rw,user=domainmyuser,password=secret
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Unfortunately, the additional output in dmesg is not helpful to figure out the problem:

# dmesg
[. ]
[16444886.307684] CIFS: Attempting to mount //server/Share
[16444886.307717] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[16444886.539770] Status code returned 0xc000006d STATUS_LOGON_FAILURE
[16444886.539795] CIFS VFS: \server Send error in SessSetup = -13
[16444886.539901] CIFS VFS: cifs_mount failed w/return code = -13

After additional try and errors (and looking up a recent share mount from the history), the problem turned out to be the user=domainmyuser syntax. This way of combining the domain/workgroup and the username is not working (anymore).

Note: Both user= and username= are accepted in the options.

# mount -t cifs «//server/Share» /mnt -o «user=myuser,password=secret,workgroup=DOMAIN»
root@focal:

# ll /mnt/
total 0
drwxr-xr-x 2 root root 0 Sep 1 2020 _Archiv
drwxr-xr-x 2 root root 0 Aug 9 12:10 Client
[..]

This way it worked.

Of course the password should not be used on the command line, so for the final (and automatic) mount of the share use the following entry in /etc/fstab:

# cat /etc/fstab
[. ]
# Mount CIFS share from server
//server/Share /mnt cifs rw,relatime,vers=3.1.1,credentials=/etc/samba/servershare.conf,uid=0 0 0

Where /etc/samba/servershare.conf contains the credentials:

# cat /etc/samba/servershare.conf
user=myuser
password=secret
domain=DOMAIN

ck from Switzerland wrote on Nov 29th, 2022:

Keith, make sure you have the cifs-utils and smbclient packages installed on your Ubuntu. Still an error? Try to connect to the share using the smbclient command. It could also be a SMB protocol mismatch. Check out this article, describing Samba protocol configuration on the client.

Keith from United States wrote on Nov 29th, 2022:

I’ve tried for the past 3 hours, 5AM in the morning now, and I’ve tried everything from every other website and this one and still get the exact same errors. Tried it with just sudo, then root. Same thing. Host OS is ubuntu server trying to mount a network share from my Synology NAS.

AJav from wrote on Sep 19th, 2022:

very good, Thanks !

simonpunk2016 from wrote on Aug 1st, 2022:

Thank you sir, never know the mount option has changed, because I just successfully mounted the cifs last month, thought my Manjaro has come to an end.

simonpunk2016 from wrote on Jul 29th, 2022:

Thank you sir, never know the mount option has changed, because I just successfully mounted the cifs last month, thought my Manjaro has come to an end.

Jesko from wrote on Feb 10th, 2022:

I had exact the same error, but different reason. On a freshly installed (old) Ubuntu 16.04 LTS (last 32Bit version). My reason was: There was no cifs-utils installed! so «sudo apt install cifs-utils» was the solution. I just write here because I crawled through hundreds of comments.

Blog Tags:

© 2008 — 2023 by Claudio Kuenzler. Powered by .

Источник

Источник

Bit of extra information here; it happened again for me today and while it was in a bad state I was able to open my docker settings and reset the credentials on my shared drives. This has had the effect of making me unable to re-share the drives. When I check the share-box next to my C drive then enter my user credentials to authorize the share, the program processes for a moment, then unchecks the box.

It required restarting the docker service to be able to re-share the drive

The following was logged to the docker logs:

[13:23:39.719][SambaShare     ][Info   ] Removing share C
[13:23:39.826][SambaShare     ][Info   ] Mount C
[13:23:39.888][Cmd            ][Info   ] This shared resource does not exist.
[13:23:39.888][Cmd            ][Info   ] More help is available by typing NET HELPMSG 2310.
[13:23:39.892][SambaShare     ][Info   ] "C" is not shared
[13:23:39.892][SambaShare     ][Info   ] Creating share "C:" as "C" with Full Control to "warrenspe"
[13:23:39.977][Cmd            ][Info   ] C was shared successfully.
[13:23:40.059][Cmd            ][Info   ] Share name        C
[13:23:40.059][Cmd            ][Info   ] Path              C:
[13:23:40.059][Cmd            ][Info   ] Remark            
[13:23:40.059][Cmd            ][Info   ] Maximum users     No limit
[13:23:40.060][Cmd            ][Info   ] Users             
[13:23:40.060][Cmd            ][Info   ] Caching           Caching disabled
[13:23:40.060][Cmd            ][Info   ] Permission        (me - hidden for github), FULL
[13:23:40.060][Cmd            ][Info   ] The command completed successfully.
[13:23:40.066][SambaShare     ][Info   ] "C" is shared
[13:23:40.134][SambaShare     ][Info   ] Username: (me - hidden for github)
[13:23:40.134][SambaShare     ][Info   ] Host IP: 10.0.75.1
[13:23:40.134][SambaShare     ][Info   ] Cifs options: noperm,iocharset=utf8,dir_mode=0777,nobrl,mfsymlinks,vers=3.02,domain=IDIR,sec=ntlmsspi
[13:23:40.220][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> GET /_pingn"
[13:23:40.221][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy << GET /_ping (1.001ms)n"
[13:23:40.223][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> POST /v1.39/images/load?quiet=1n"
[13:23:40.362][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy << POST /v1.39/images/load?quiet=1 (138.4283ms)n"
[13:23:40.470][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> GET /_pingn"
[13:23:40.478][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy << GET /_ping (997.3µs)n"
[13:23:40.478][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> POST /v1.39/containers/create [rewriteBinds]n"
[13:23:40.478][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="Rewrote mount /run/config/docker:/host_mnt (volumeDriver=) to /run/config/docker:/host_mnt"
[13:23:40.478][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> POST /v1.39/containers/createn"
[13:23:40.619][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy << POST /v1.39/containers/create (145.0086ms)n"
[13:23:40.624][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> POST /v1.39/containers/4ae70df298efc6017cd4d7db0c7f31b8653ad10300aa901f2d509d1552bae654/attach?stderr=1&stdin=1&stdout=1&stream=1n"
[13:23:40.631][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="Upgrading to raw stream"
[13:23:40.631][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> POST /v1.39/containers/4ae70df298efc6017cd4d7db0c7f31b8653ad10300aa901f2d509d1552bae654/wait?condition=removedn"
[13:23:40.636][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> POST /v1.39/containers/4ae70df298efc6017cd4d7db0c7f31b8653ad10300aa901f2d509d1552bae654/start [start]n"
[13:23:40.636][ApiProxy       ][Info   ] time="2019-06-12T13:23:40-07:00" msg="proxy >> POST /v1.39/containers/4ae70df298efc6017cd4d7db0c7f31b8653ad10300aa901f2d509d1552bae654/startn"
[13:23:40.646][Moby           ][Info   ] [111527.482944] docker0: port 2(vethe16695f) entered blocking state
[13:23:40.654][Moby           ][Info   ] [111527.489836] docker0: port 2(vethe16695f) entered disabled state
[13:23:40.660][Moby           ][Info   ] [111527.496903] device vethe16695f entered promiscuous mode
[13:23:40.667][Moby           ][Info   ] [111527.503330] IPv6: ADDRCONF(NETDEV_UP): vethe16695f: link is not ready
[13:23:40.672][Moby           ][Info   ] [111527.510888] docker0: port 2(vethe16695f) entered blocking state
[13:23:40.676][Moby           ][Info   ] [111527.514311] docker0: port 2(vethe16695f) entered forwarding state
[13:23:40.691][Moby           ][Info   ] [111527.530088] docker0: port 2(vethe16695f) entered disabled state
[13:23:40.743][Moby           ][Info   ] [111527.583477] IPVS: Creating netns size=2104 id=40
[13:23:40.747][Moby           ][Info   ] [111527.586642] IPVS: ftp: loaded support on port[0] = 21
[13:23:40.877][Moby           ][Info   ] [111527.711102] eth0: renamed from vethe648ab8
[13:23:40.922][Moby           ][Info   ] [111527.760671] IPv6: ADDRCONF(NETDEV_CHANGE): vethe16695f: link becomes ready
[13:23:40.934][Moby           ][Info   ] [111527.765551] docker0: port 2(vethe16695f) entered blocking state
[13:23:40.945][Moby           ][Info   ] [111527.776651] docker0: port 2(vethe16695f) entered forwarding state
[13:23:41.046][ApiProxy       ][Info   ] time="2019-06-12T13:23:41-07:00" msg="proxy << POST /v1.39/containers/4ae70df298efc6017cd4d7db0c7f31b8653ad10300aa901f2d509d1552bae654/start (410.5538ms)n"
[13:23:41.177][Moby           ][Info   ] [111528.014625] CIFS VFS: cifs_mount failed w/return code = -5
[13:23:41.232][ApiProxy       ][Info   ] time="2019-06-12T13:23:41-07:00" msg="proxy << POST /v1.39/containers/4ae70df298efc6017cd4d7db0c7f31b8653ad10300aa901f2d509d1552bae654/attach?stderr=1&stdin=1&stdout=1&stream=1 (608.5765ms)n"
[13:23:41.249][Moby           ][Info   ] [111528.088915] docker0: port 2(vethe16695f) entered disabled state
[13:23:41.252][Moby           ][Info   ] [111528.092604] vethe648ab8: renamed from eth0
[13:23:41.351][Moby           ][Info   ] [111528.191313] docker0: port 2(vethe16695f) entered disabled state
[13:23:41.355][Moby           ][Info   ] [111528.195654] device vethe16695f left promiscuous mode
[13:23:41.359][Moby           ][Info   ] [111528.199100] docker0: port 2(vethe16695f) entered disabled state
[13:23:41.672][ApiProxy       ][Info   ] time="2019-06-12T13:23:41-07:00" msg="proxy << POST /v1.39/containers/4ae70df298efc6017cd4d7db0c7f31b8653ad10300aa901f2d509d1552bae654/wait?condition=removed (1.0403149s)n"
[13:23:41.683][SambaShare     ][Error  ] Unable to mount C drive: 10.0.75.1 (10.0.75.1:445) open
rm: cannot remove '/c': No such file or directory
rm: cannot remove '/C': No such file or directory
umount: /host_mnt/c: not mounted.
mount.cifs kernel mount options: ip=10.0.75.1,unc=\10.0.75.1C,noperm,iocharset=utf8,dir_mode=0777,nobrl,mfsymlinks,vers=3.02,sec=ntlmsspi,user=WASPENCE,domain=IDIR,pass=********
mount error(5): I/O error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Источник

PERMISSION DENIED

PERMISSION DENIED (Photo by Hidde van Esch on Unsplash)

If you recently updated your RedHat or CentOS 7.6 system, you may suddenly start getting “Permission Denied” errors when attempting to mount SMB shares via CIFS. Typical error messages in syslog look like this:

kernel: Status code returned 0xc000006d STATUS_LOGON_FAILURE
kernel: CIFS VFS: Send error in SessSetup = -13
kernel: CIFS VFS: cifs_mount failed w/return code = -13

Configuration that triggered the problem

  • Synology NAS with latest operating system shares a volume via SMB
  • CentOS 7 Linux server mounts SMB share using a local username and password (NOT domain credentials)
  • cifs-utils version 6.2 installed in May of 2019 (this by itself worked fine)
  • libsmbclient just updated to 4.9.1-6
  • libmount just updated to 2.23.2-61
  • CIFS mount options: vers=3.0,credentials=/root/credentials.txt,sec=ntlmsspi
  • File /root/credentials.txt contained a username and password that are LOCAL to the SMB server

Troubleshooting & solution

I was able to isolate the problem to mount.cifs with the following procedure:

  1. Mount the SMB share from a Windows host, using the same credentials as the Linux host. This proved that the credentials were valid and there were no problems on the SMB server side.
  2. Access the SMB share from the Linux host using smbclient. This step ruled out any network issues between the Linux and SMB server, and verified that the version of Samba installed on the Linux host was compatible with the SMB server.

I found the solution in a post from a couple of years ago in the askubuntu forum on StackExchange. It seems that one of the recent CentOS/RedHat updates changed some default behavior in the way that mount.cifs authenticates to SMB shares. When authenticating as a local user, you now have to specify the host as the domain. I did this by adding one line to the credentials file that is referenced from /etc/fstab as shown below:

//172.1.1.1/share_name      /mnt/mountpoint        cifs    vers=3.0,credentials=/root/credentials.txt,sec=ntlmsspi

Here are the contents of file /root/credentials.txt:

username=my_username
password=my_password
domain=172.1.1.1

I am not sure why this problem showed up now; it seems like it should have occurred months ago when we updated to latest version of cifs-utils. I’m also unsure if this problem will occur if you’re attempting to authenticate as a domain user. Let me know in the comments!

Источник

I tried to mount manually on my Linux shared folders from windows server 2012 R2.

The syntaxe is right but Im stuck on the same issue error 13:

#mount.cifs //ip/division /mnt/division -o username=bob@dude-uk,password=myscretpass,vers=2.1
dmesg:
Status code returned 0xc000006d STATUS_LOGON_FAILURE
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13

If I tried other vers= options I got the same issue.
If I remove the option vers= then syslog claim :

No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.

If I use option sec= then I specify this option then I got error 126

#mount.cifs //ip/division /mnt/division -o username=bob@dude-uk,password=myscretpass,vers=2.1,sec=krb5
mount error(126): Required key not available

Package Keyutils is installed.

If I tried other sec= options I got error 22 or error 13

if I tried to prompt the password:

#mount.cifs //ip/division /mnt/division -o username=bob@dude-uk
Password for bob@dude-uk@//ip/division:  
mount error(13): Permission denied

Nemo (file explorer in Linux Mint) can mount the shared folders.
MacOsx can mount shared folders.

My kernel is 4.13
Mount.cifs is 6.4
I tried to mount manually before setup my fstab.

Do you have any idea ?

Источник

Issue

  • We have a CIFS mount which currently appears to be working as expected, but we see the following error constantly:
kernel: CIFS VFS: SMB signature verification returned error = -13
kernel: CIFS VFS: SMB signature verification returned error = -13
kernel: CIFS VFS: SMB signature verification returned error = -13

Environment

  • Red Hat Enterprise Linux 7.1
  • kernel-3.10.0-229.14.1.el7.x86_64
  • CIFS client mounting Samba or Windows SMB export

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

Источник
  • Home
  • Forum
  • The Ubuntu Forum Community
  • Ubuntu Specialised Support
  • Ubuntu Servers, Cloud and Juju
  • Server Platforms
  • [ubuntu] 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

  1. 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    I have two 20.04 machines, while host A has a samba share which I want to mount on host B using cifs with password file (for use in fstab)

    When I use clear text credentials in the mount-command it works:

    Code:

    mount -t cifs -o username=USERNAME,password=PASSWORD //192.168.40.206/SHARE /var/MOUNTPOINT

    Then I created a file .smbcredentials owned by root with 600 permissions (I double checked theres no hidden spaces or blank lines in that file. I don’t have a windows domain, so theres no third line for domain, however I already tested with the line domain=WORKGROUP at the bottom of the file):

    Code:

    username=USERNAME
password=PASSWORD

    Trying to use this password file:

    Code:

    mount -t cifs -o credentials=/home/sadmin/.smbcredentials //192.168.40.206/SHARE /var/MOUNTPOINT

    I receive this error message:

    Code:

    mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

    dmesg deliveres this output:

    Code:

    [ 6445.020992] CIFS: Attempting to mount //192.168.40.206/SHARE[ 6445.021014] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 6445.030391] Status code returned 0xc000006d STATUS_LOGON_FAILURE
[ 6445.030397] CIFS VFS: \192.168.40.206 Send error in SessSetup = -13
[ 6445.031992] CIFS VFS: cifs_mount failed w/return code = -13

    Since both machines are the same 20.04 with latest updates I don’t see a reason for a difference in used SMB versions, however, I verified all possible versions are supported (I also tried option vers=3.11 and all others until 2.02):

    Code:

    nmap --script smb-protocols 192.168.40.206Starting Nmap 7.80 ( https://nmap.org ) at 2022-01-08 20:42 UTC
Nmap scan report for fileserver.fritz.box (192.168.40.206)
Host is up (0.00092s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds
MAC Address: 00:0C:29:6C:D9:77 (VMware)

Host script results:
| smb-protocols:
|   dialects:
|     2.02
|     2.10
|     3.00
|     3.02
|_    3.11
 Nmap done: 1 IP address (1 host up) scanned in 0.61 seconds

    Since everything works when I type the credentials in the mount command, there’s no issue with the credentials itself and no issue with the permission structure on the Host A with the share. Windows machines have no issues using this share.

    Any ideas or hints to check?

  2. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    Try:

    Code:

    sudo mount -t cifs -o credentials=/home/sadmin/.smbcredentials //192.168.40.206/SHARE /var/MOUNTPOINT

    Mount requires sudo in this situation.

    This assumes the SHARE is correct and the /var/MOUNTPOINT exists. BTW, mounting CIFS storage under /var is unlikely to be a good idea. Probably best to mount it under /media. That will allow snap packages to have a chance to access it. /var expects Unix file systems, not CIFS.

  3. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    sorry, I forgot to mention, I did all my testings as root

    anyway I gave it a try to mount in /media/testmount > same error

  4. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    This may sound dumb on my part, but I assume that package cifs-utils is installed right? It being missing is sometimes the culprit when trying to use a credential file.

    Also the format of the credential file, if it is saved as UTF-8, then if it has UTF-8 BOM encoding characters at the start of that file (0xEF, 0xBB, 0xBF).

    One other thing looking at the manpages, the format is

    Code:

    mount.cifs { service } { mount-point } [ -o options ]

    Where options are shown listed as last… And most of the time, if I am using multiple options, I still put the credential file option at the end of those other options…I was told that the order of the option precedence, are the same as in the fstab file… In that whatever is listed to the right will take precedence, of the previous listed to the left of those…

    Code:

    sudo mount -t cifs //192.168.40.206/SHARE /var/MOUNTPOINT -o credentials=/home/sadmin/.smbcredentials

    That may not matter, but just how I saw that… I know Morpheus had to help me with that about 11 years ago when it was driving me crazy trying to figure out what was wrong with one of my NAS mounts. I know how frustrating that can be.

    EDIT:
    The curious thing about that error return code, I looked it up in the Microsoft CIFS Docs, and I don’t see -13 as a return code that I can find in any of the tables.
    https://docs.microsoft.com/en-us/ope…6-f00569e3e1bc
    Now that has me searching for it further.

    EDIT2:
    I found it in the RedHat CIFS Docs, returns a «-13» after this error:

    Code:

    Status code returned 0xc000006d  NT_STATUS_LOGON_FAILURE

    Look at your Credential File for extraneous characters…

    Last edited by MAFoElffen; January 11th, 2022 at 12:20 PM.

    Reason: Had to add spaces in an example or the Forums software was interpreting it as something different(?)

  5. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    13 is a common error meaning «permission denied» in Unix-speak.

  6. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    thank you very much for your investigation

    I tried:

    Code:

    sudo mount -t cifs //192.168.40.206/SHARE /var/MOUNTPOINT -o credentials=/home/sadmin/.smbcredentials

    Same error

    I re-created the credentials file using Nano and again using vim. Same result.

  7. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    Sounds like it is time to capture debug info or network traces… To at least narrow down what might be happening.

    As root, you can tuen on cifs debugging, which will go to the Syslog and seen with dmesg:

    Code:

    modprobe cifs
echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control
echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control
echo 7 > /proc/fs/cifs/cifsFYI

    «7» is an anomaly… any non-zero value will turn debugging on

    The pertinent messages in dmesg:

    Code:

    demesg | grep -i "CIFS VFS:"

    To turn off cifs debugging:

    Code:

    echo 0 > /proc/fs/cifs/cifsFYI

    To capture network traffic between the host and client, I usually use WireShark and filter on the two network addresses and SMB… But you could also do a netdump on:

    Code:

    tcpdump -i eth0 -s200 -w /tmp/cifs-traffic.pcap host cifs_server.example.com and port 445

  8. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    Quote Originally Posted by techvic
    View Post

    I re-created the credentials file using Nano and again using vim. Same result.

    My first guess is that there is an extra space at the end of the password in the credentials file. A common issue for everyone. We habitually add a space after typing a word.

    If the other system isn’t Windows, you can also NOT use CIFS, but use NFS instead. NFS is system-to-system and typically 20% faster than CIFS. I know that Windows supports NFS, but not in an easy way, so I wouldn’t suggest anyone do that with Windows as the NFS server. Almost all NAS devices support NFS and it should be used for Unix-like OSes over CIFS.

  9. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    Here’s the dmesg-Output with turned on debugging:

    Code:

    [  316.833258] CIFS: fs/cifs/fs_context.c: CIFS: parsing cifs mount option 'source'[  316.833265] CIFS: fs/cifs/fs_context.c: CIFS: parsing cifs mount option 'ip'
[  316.833268] CIFS: fs/cifs/fs_context.c: CIFS: parsing cifs mount option 'unc'
[  316.833269] CIFS: fs/cifs/fs_context.c: CIFS: parsing cifs mount option 'user'
[  316.833271] CIFS: fs/cifs/fs_context.c: CIFS: parsing cifs mount option 'pass'
[  316.833273] CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[  316.833274] CIFS: fs/cifs/cifsfs.c: Devname: \192.168.40.206SHARE flags: 0
[  316.833278] CIFS: fs/cifs/connect.c: Username: rsfs2user
[  316.833279] CIFS: fs/cifs/connect.c: file mode: 0755  dir mode: 0755
[  316.833281] CIFS: fs/cifs/connect.c: VFS: in mount_get_conns as Xid: 0 with uid: 0
[  316.833283] CIFS: fs/cifs/connect.c: UNC: \192.168.40.206SHARE
[  316.833287] CIFS: fs/cifs/connect.c: generic_ip_connect: connecting to 192.168.40.206:445
[  316.833294] CIFS: fs/cifs/connect.c: Socket created
[  316.833295] CIFS: fs/cifs/connect.c: sndbuf 16384 rcvbuf 131072 rcvtimeo 0x6d6
[  316.833955] CIFS: fs/cifs/fscache.c: cifs_fscache_get_client_cookie: (0x00000000d0228e43/0x00000000d0731b3a)
[  316.833959] CIFS: fs/cifs/connect.c: cifs_get_tcp_session: next dns resolution scheduled for 600 seconds in the future
[  316.833961] CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 1 with uid: 0
[  316.833963] CIFS: fs/cifs/connect.c: Existing smb sess not found
[  316.833966] CIFS: fs/cifs/smb2pdu.c: Negotiate protocol
[  316.833973] CIFS: fs/cifs/transport.c: wait_for_free_credits: remove 1 credits total=0
[  316.833985] CIFS: fs/cifs/transport.c: Sending smb: smb_len=244
[  316.834015] CIFS: fs/cifs/connect.c: Demultiplex PID: 1435
[  316.843099] CIFS: fs/cifs/connect.c: RFC1002 header 0x10c
[  316.843109] CIFS: fs/cifs/smb2misc.c: SMB2 data length 74 offset 128
[  316.843111] CIFS: fs/cifs/smb2misc.c: SMB2 len 202
[  316.843112] CIFS: fs/cifs/smb2misc.c: length of negcontexts 60 pad 6
[  316.843114] CIFS: fs/cifs/smb2ops.c: smb2_add_credits: added 1 credits total=1
[  316.843124] CIFS: fs/cifs/transport.c: cifs_sync_mid_result: cmd=0 mid=0 state=4
[  316.843154] CIFS: fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[  316.843157] CIFS: fs/cifs/smb2pdu.c: mode 0x1
[  316.843158] CIFS: fs/cifs/smb2pdu.c: negotiated smb3.1.1 dialect
[  316.843161] CIFS: fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[  316.843163] CIFS: fs/cifs/smb2pdu.c: decoding 2 negotiate contexts
[  316.843164] CIFS: fs/cifs/smb2pdu.c: decode SMB3.11 encryption neg context of len 4
[  316.843165] CIFS: fs/cifs/smb2pdu.c: SMB311 cipher type:2
[  316.843167] CIFS: fs/cifs/connect.c: Security Mode: 0x1 Capabilities: 0x300047 TimeAdjust: 0
[  316.843168] CIFS: fs/cifs/smb2pdu.c: Session Setup
[  316.843169] CIFS: fs/cifs/smb2pdu.c: sess setup type 4
[  316.843171] CIFS: fs/cifs/transport.c: wait_for_free_credits: remove 1 credits total=0
[  316.843180] CIFS: fs/cifs/transport.c: Sending smb: smb_len=124
[  316.844444] CIFS: fs/cifs/connect.c: RFC1002 header 0xf2
[  316.844448] CIFS: fs/cifs/smb2misc.c: SMB2 data length 170 offset 72
[  316.844449] CIFS: fs/cifs/smb2misc.c: SMB2 len 242
[  316.844451] CIFS: fs/cifs/smb2ops.c: smb2_add_credits: added 1 credits total=1
[  316.844456] CIFS: fs/cifs/transport.c: cifs_sync_mid_result: cmd=1 mid=1 state=4
[  316.844458] CIFS: Status code returned 0xc0000016 STATUS_MORE_PROCESSING_REQUIRED
[  316.844462] CIFS: fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc0000016 to POSIX err -5
[  316.844466] CIFS: fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[  316.844468] CIFS: fs/cifs/smb2pdu.c: rawntlmssp session setup challenge phase
[  316.851129] CIFS: fs/cifs/transport.c: wait_for_free_credits: remove 1 credits total=0
[  316.851144] CIFS: fs/cifs/transport.c: Sending smb: smb_len=330
[  316.852080] CIFS: fs/cifs/connect.c: RFC1002 header 0x49
[  316.852086] CIFS: fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[  316.852087] CIFS: fs/cifs/smb2misc.c: SMB2 len 73
[  316.852089] CIFS: fs/cifs/smb2ops.c: smb2_add_credits: added 1 credits total=1
[  316.852096] CIFS: fs/cifs/transport.c: cifs_sync_mid_result: cmd=1 mid=2 state=4
[  316.852099] CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE
[  316.852102] CIFS: fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc000006d to POSIX err -13
[  316.852104] CIFS: fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[  316.852107] CIFS: VFS: \192.168.40.206 Send error in SessSetup = -13
[  316.852143] CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 1) rc = -13
[  316.852146] CIFS: fs/cifs/dfs_cache.c: __dfs_cache_find: search path: 192.168.40.206SHARE
[  316.852148] CIFS: fs/cifs/dfs_cache.c: get_dfs_referral: get an DFS referral for 192.168.40.206SHARE
[  316.852154] CIFS: fs/cifs/fscache.c: cifs_fscache_release_client_cookie: (0x00000000d0228e43/0x00000000d0731b3a)
[  316.852160] CIFS: fs/cifs/connect.c: VFS: leaving mount_put_conns (xid = 0) rc = 0
[  316.852161] CIFS: VFS: cifs_mount failed w/return code = -13

    I have a tcpdump as well, however, I assume in there are visible credentials, so I can’t post it here online without understanding it’s content to remove any real information

  10. Re: 20.04 mount cifs with password file: cifs_mount failed w/return code = -13

    Try a manual mount with verbose options.

    Code:

    sudo mount -vvvv -t cifs //192.168.40.206/SHARE /var/MOUNTPOINT -o credentials=/home/sadmin/.smbcredentials

    I’m guessing there is something formatted wrong with the credentials and expect an error like:

    Credential formatted incorrectly: (null)

    Does /var/MOUNTPOINT already exist?

Bookmarks

Bookmarks


Posting Permissions

Источник

Понравилась статья? Поделить с друзьями:
  • Cisco anyconnect secure mobility client error 1722
  • Cifs vfs send error in read 11
  • Cifs vfs send error in close 512
  • Cifs vfs error connecting to socket aborting operation
  • Cifs mount error 127 key has expired