40

The command mount.cifs is found not being able to run in a gentoo system with systemd

ae429-1105 etc # mount -t cifs //file.abc.edu.au/user /home/directory/path -o credentials=/etc/user,rw,iocharset=utf8,file_mode=0777,dir_mode=0777 mount error(2): No such file or directory Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

It has been confirmed that the existence and accessibility of the mountpoint /home/directory/path and credential file /etc/user. Also the relevant modules and services has been enabled, i.e.,

 ae429-1105 etc # lsmod |egrep 'fuse|cifs' fuse 72589 5 cifs 312131 0

and

ae429-1105 etc # systemctl -t service -a |grep Samba nmbd.service loaded active running Samba NetBIOS name server smbd.service loaded active running Samba SMB/CIFS server winbindd.service loaded inactive dead Samba Winbind daemon

This problem has been identified by many users, e.g. one example . ALSO NOTE that the same command executed in my Ubuntu/debian system is able to mount successfully.

Other information in the problematic machine:

ae429-1105 etc # mount.cifs --version mount.cifs version: 6.1

the version of mount.cifs installed in debian/ubuntu is 6.0

Improve this question
4
  • /home/directory/path is certain to exist in the Gentoo environment? Strange that you don't mention that as this is the obvious first question which arises. Commented Mar 21, 2014 at 0:58
  • Yes, I have confirmed the existence and accessibility of the mount point /home/directory/path. Commented Mar 21, 2014 at 1:00
  • You should add this information to the question so that other readers need not read the comments to get it. Commented Mar 21, 2014 at 1:08
  • In my case, the local IP Address was incorrect thus, I was getting this error. Commented Mar 27, 2022 at 9:23

14 Answers 14

Reset to default
23

You might need to provide the vers= option to the mount command to force version 3.0 if you're trying to mount a share from a newer version of Windows. One of our fileservers was recently upgraded to 2012R2 and that's when my mount stopped working. Setting it to vers=3.0 fixed the issue. Like most Samba/CIFS errors the "No such file or directory" message isn't much help.

As an example:

# mount -t cifs //win2012r2/someshare -o cred=/home/foo/.cifs_user,vers=3.0 /mnt/tmp

..where I have my domain, username and password contained in the .cifs_user file:

user=MyUser password=MyPassword domain=MyDomain

Apparently, smbmount uses a newer version of the SMB protocol by default since it worked without issue or any special options.

Notice below that the default protocol version is 1.0.

From the mount.cifs man page:

vers=arg SMB protocol version. Allowed values are: · 1.0 - The classic CIFS/SMBv1 protocol. · 2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and Windows Server 2008. Note that the initial release version of Windows Vista spoke a slightly different dialect (2.000) that is not supported. · 2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2. · 3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012. · 3.02 or 3.0.2 - The SMBv3.0.2 protocol that was introduced in Microsoft Windows 8.1 and Windows Server 2012R2. · 3.1.1 or 3.11 - The SMBv3.1.1 protocol that was introduced in Microsoft Windows 10 and Windows Server 2016. · 3 - The SMBv3.0 protocol version and above. · default - Tries to negotiate the highest SMB2+ version supported by both the client and server. If no dialect is specified on mount vers=default is used. To check Dialect refer to /proc/fs/cifs/DebugData Note too that while this option governs the protocol version used, not all features of each version are available. The default since v4.13.5 is for the client and server to negotiate the highest possible version greater than or equal to 2.1. In kernels prior to v4.13, the default was 1.0. For kernels between v4.13 and v4.13.5 the default is 3.0.
Improve this answer
6
  • I had a similar problem with the "nounix" flag which must not be supported in v1.0. Changing to v2.0 (the most recent available for me) fixed the problem. Also file permissions are more sensible with vers=2.0 (755 instead of 777) Commented Aug 12, 2017 at 21:10
  • 4
    Thanks a lot for the solution related to vers= option! It worked for me, only backwards...After upgrading opensuse leap from 42.3 version to 15.1, an fstab entry for mounting a network drive, which worked, stopped working in 15.1. I used the option vers=1.0 and guess what...Probably leap 15.1 uses a newer version of SMB protocol that was not able to find the remote directory. Commented Jul 13, 2019 at 14:54
  • 1
    Connecting to a share hosted on Windows Server 2003 from Ubuntu 19.04 continually failed for me until I added vers=1.0 to my options list. Thanks! Commented Aug 12, 2019 at 21:03
  • It worked for me, EXCEPT: I had to state Version TWO vers=2.0 to mount the samba shares of my 5-year-old NAS system... with 3.0 I got above error. Commented Sep 8, 2019 at 13:15
  • etc/fstab users: Just put that vers=3.0 (or 2.0...) right and spaceless before your other options, i.e. vers=2.0,guest,uid=1000,iocharset… Commented Sep 8, 2019 at 13:16
13

Try to install the package keyutils:

sudo apt-get install keyutils

Not sure exactly why this helps, maybe someone else has an answer here. But at least it did the trick for me: with keyutils the cifs mount worked just fine.

Improve this answer
4
  • Please add some information on how this would resolve the problem stated in the question. What does this package do, and how does it figure into the problem raised by the OP? Commented Mar 20, 2019 at 15:03
  • 1
    Good question. I am not sure how the package keyutils helps. In my case at least this is what did the trick. After install of keyutils, my cifs mount worked just fine, whereas before I did get the error message "mount error(2): No such file or directory", just as in the OP. Commented Mar 24, 2019 at 11:41
  • Duplicate of this other answer Commented Jul 13, 2019 at 15:36
  • It's works for ubuntu 20.04 ... I am not sure how the package keyutils helps too.. Commented May 12, 2022 at 8:51
12

Can you use nodfs option? ie for your -o options input pass the input as below.

-o credentials=/etc/user,rw,iocharset=utf8,file_mode=0777,dir_mode=0777,nodfs

i.e appended ,nodfs

It worked for me.

Improve this answer
3
  • thank you! I tried all other suggestions first, but I needed this on fedora30 where I did not need it before Commented Jul 26, 2019 at 10:40
  • nodfs worked for me, but so did installing the keyutils package Commented Jun 24, 2020 at 9:56
  • Thanks! The nodfs option is necessary to mount a NTFS share on a CentOS 8. However, it is not necessary on CentOS 7. Commented Oct 28, 2020 at 9:52
6

I ran into this on Ubuntu 18.04. The problem was I needed the keyutils package to do Kerberos authentication (sec=krb5 mount option), which was not installed along with cifs-utils (which provided mount.cifs). I'm not sure if the package name is the same on Gentoo or not. (Thanks to https://forum.zentyal.org/index.php?topic=18601.0 for the solution.)

Improve this answer
4

You might need to change the sec parameter: this setting made it work on my setup:

mount.cifs ... -o sec=ntlm

Relevant extract of man mount.cifs:

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.

    If the server requires signing during protocol negotiation, then it may be enabled automatically. Packet signing may also be enabled automatically if it's enabled in /proc/fs/cifs/SecurityFlags.

Improve this answer
1
  • 1
    ntlmssp is what did it for me. Thanks! Commented Nov 6, 2020 at 14:17
2

I wanted to add another source of this problem I encountered today. Once you change the user id of a unix user, the smb user created via smbpasswd may not able to authenticate for the samba share anymore resulting in the same error.

So if you changed your unix user id via usermod -u 1000 my_user then you may run into problems. The fix for me was to delete and re-add the smb user afterwards:

 smbpasswd -x my_user smbpasswd -a my_user
Improve this answer
2
  • 1
    While true, how is this related to the original question? Commented Jun 16, 2019 at 14:12
  • 2
    As I said, if you change the user id of a user, the same error of the original question appears. So if anyone did the same and finds this thread, he or she might find my hint useful. Commented Jun 17, 2019 at 19:24
1

I was running into this same "mount error(2): No such file or directory" error using mount.cifs on a CentOS 7 VM. I never determined exactly why the error was being generated when using the default ntlm security (and the variants), but I did discover that using Kerberos authentication worked around the problem. So my final working command line looked like this:

mount.cifs -v -o domain=MYCODOMAIN,sec=krb5 //winserver/sharename /mnt/mymountpoint

whereas this command that gave the "no such file or directory" error was:

mount.cifs -v -o username=myusername,domain=MYCODOMAIN //winserver/sharename /mnt/mymountpoint

To use Kerberos, I installed "krb5-workstation" package and configured it.

Improve this answer
1

Add a $ to the end, like this //winserver/sharename$

mount.cifs -v -o username=myusername,domain=MYCODOMAIN //winserver/sharename$ /mnt/mymountpoint
Improve this answer
2
  • Wow! Any idea what the '$' does? It fixed it for me but no clue to why Commented Jun 28, 2019 at 20:22
  • 1
    The $ sign is an administrative share in the Windows share context, if activated by the system, a user with administrative rights can access all paths. Example \\MY-SERVER\c$ Commented Oct 25, 2019 at 9:31
1

With me it worked by putting "vers = 1.0" as before -> credentials = / root / .dbx.credentials, vers = 1.0, uid = 1001, gid = 100, rw

Improve this answer
1

Could you have just upgraded the linux kernel?

Are you on a corporate network?

If so - try disabling IPv6 in /etc/sysctl.conf

to do this open it with sudo nano /etc/sysctl.conf and add the following:

net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1

And then run sudo sysctl -p

Remount and try again.

This worked for me when I upgraded LTS all the way from 16.04 through 18.04 to 20.04, and I had this problem.

Improve this answer
0

One solution might be to manually install keyutils since it is not a (hard) dependency of cifs-utils anymore.

Information why keyutils are not installed anymore can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822841

And a launchpad bug report can be found here: https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1772148

Improve this answer
0

Apparently samba throws this entirely un-helpful error in an astoundingly wide range of cases. In my case, the issue was an option configured for the share in the server's smb.conf (vfs objects = vfs_fruit) which the server didn't like, even though testparm didn't complain about it.

Improve this answer
0

This error could mean a variety of things. Scenario I saw was that Samba on the server had been updated, but the service was not restarted. This caused it to have errors loading shared modules. Restarting Samba on the server resolved. So: check the server logs and consider restarting Samba.

Improve this answer
0

I got this error because I was using a hardened Ubuntu VM and the firewall was blocking the outgoing connection. I checked sudo ufw status verbose, found outgoing connections were not always allowed, and then added the relevant ports:

ufw allow out from any to a.b.c.d port 137 proto udp ufw allow out from any to a.b.c.d port 138 proto udp ufw allow out from any to a.b.c.d port 139 proto tcp ufw allow out from any to a.b.c.d port 445 proto tcp

where a.b.c.d should be replaced with the remote server's IP address.

EDIT: The error output included the line:

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

so I ran dmesg and spotted these two lines, which set me on the right track:

[ 6331.419294] CIFS VFS: Error connecting to socket. Aborting operation. [ 6331.419581] CIFS VFS: cifs_mount failed w/return code = -2
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.