Mounting a share in fstab fails with BAD_NETWORK_NAME

[Daniel Essin]

The following command works:
mount -t cifs //192.168.1.200/Drive_E /mnt/server_e -o credentials=/root/.smbcredentials_server

The following fstab entry fails:
//server/Server_E /mnt/server_e cifs uid=0,credentials=/root/.smbcredentials_server,file_mode=0755,dir_mode=0755,vers=2.1,sec=ntlmssp 0 0

There is an entry in hosts for server. It also fails with //192.168.1.200/Server_E
Sometimes it says:
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.
[ 2079.955734] CIFS VFS: BAD_NETWORK_NAME: \\192.168.1.200\Server_E
CIFS VFS: cifs_mount failed w/return code = -2

trying vers=1.0 and vers=3.0 makes no difference.

There is no documentations of CIFS VFS error codes
There is no documentation of how to specify the SMB dialect.
People appear to have been having trouble with these things for at least the past 10 years.

I never had a problem with this on debian.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: samba 2:4.11.6+dfsg-0ubuntu1.4
ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55
Uname: Linux 5.4.0-47-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia ufsd
ApportVersion: 2.20.11-0ubuntu27.8
Architecture: amd64
CIFSMounts: /root/smb4k/192.168.1.200/Drive_E //192.168.1.200/Drive_E cifs rw,relatime,vers=3.1.1,cache=strict,username=essin,domain=WORKGROUP,uid=0,forceuid,gid=0,forcegid,addr=192.168.1.200,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
Date: Tue Sep 22 17:35:02 2020
InstallationDate: Installed on 2020-09-18 (4 days ago)
InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
ProcEnviron:
 LANGUAGE=en_US
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SambaClientRegression: Yes
SourcePackage: samba
UpgradeStatus: No upgrade log present (probably fresh install)

[Chris Guiver (guiverc)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Bug reporting is mostly about finding & fixing problems thus preventing future users from hitting the same bug.

I suspect a Support site would be more appropriate, eg. https://answers.launchpad.net/ubuntu. You can also find help with your problem in the support forum of your local Ubuntu community http://loco.ubuntu.com/ or asking at https://askubuntu.com or https://ubuntuforums.org, or for more support options please look at https://discourse.ubuntu.com/t/community-support/709

[Daniel Essin (essin)]

Hi Chris,
That’s nice but I’ve crawled all over the support sites and the web. Many have reported and discussed this and related problems mounting shares in 20.04 but no one has either explained the cause of the problem or offered a definitive solution.

Based on the existence of the problem and the lack of any documentation or solution leads me to conclude that this is in fact a bug and not a support issue.
This reminds me of a problem that I had with a Mac that spontaneously crashed and restarted with an error code that Apple never documented and which none of the “support” staff had been “trained” on.

When mount works from the command-line but not from fstab (with correct syntax) the only possible explanation is that it is a bug. The BAD_NETWORK_NAME can’t really be bad if it works in the mount command. btw - smb4k also has no problem mounting this share, but it is not persistent between reboots.

On Tue, Sep 22, 2020, at 7:33 PM, Chris Guiver wrote:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better.
>
> Bug reporting is mostly about finding & fixing problems thus preventing
> future users from hitting the same bug.
>
> I suspect a Support site would be more appropriate, eg.
> https://answers.launchpad.net/ubuntu. You can also find help with your
> problem in the support forum of your local Ubuntu community
> http://loco.ubuntu.com/ or asking at https://askubuntu.com or
> https://ubuntuforums.org, or for more support options please look at
> https://discourse.ubuntu.com/t/community-support/709
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1896699
>
> Title:
> Mounting a share in fstab fails with BAD_NETWORK_NAME
>
> Status in samba package in Ubuntu:
> New
>
> Bug description:
> The following command works:
> mount -t cifs //192.168.1.200/Drive_E /mnt/server_e -o
> credentials=/root/.smbcredentials_server
>
> The following fstab entry fails:
> //server/Server_E /mnt/server_e cifs
> uid=0,credentials=/root/.smbcredentials_server,file_mode=0755,dir_mode=0755,vers=2.1,sec=ntlmssp 0 0
>
> There is an entry in hosts for server. It also fails with
> //192.168.1.200/Server_E
> Sometimes it says:
> 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.
> [ 2079.955734] CIFS VFS: BAD_NETWORK_NAME: \\192.168.1.200\Server_E
> CIFS VFS: cifs_mount failed w/return code = -2
>
> trying vers=1.0 and vers=3.0 makes no difference.
>
> There is no documentations of CIFS VFS error codes
> There is no documentation of how to specify the SMB dialect.
> People appear to have been having trouble with these things for at
> least the past 10 years.
>
> I never had a problem with this on debian.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 20.04
> Package: samba 2:4.11.6+dfsg-0ubuntu1.4
> ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55
> Uname: Linux 5.4.0-47-generic x86_64
> ...

[Andreas Hasenack (ahasenack)]

> mount -t cifs //192.168.1.200/Drive_E /mnt/server_e -o credentials=/root/.smbcredentials_server
>
> The following fstab entry fails:
> //server/Server_E /mnt/server_e cifs uid=0,credentials=/root/.smbcredentials_server,file_mode=0755,dir_mode=0755,vers=2.1,sec=ntlmssp 0 0

> [ 2079.955734] CIFS VFS: BAD_NETWORK_NAME: \\192.168.1.200\Server_E
CIFS VFS: cifs_mount failed w/return code = -2

This error usually means the share name is incorrect. Have you checked your fstab file for extraneous characters, bad line-ending, that kind of stuff? Try "cat -vet /etc/fstab" as that will show control characters.

You also have quite different options in the fstab line versus your shown command line, but I suspect you tested many combinations already and just pasted one of the iterations.

Also, try to start with a simpler fstab line. For example:
//192.168.1.200/Drive_E /mnt/server_e cifs 0 0

And go from there if it works.

Regarding the documentation, the cifs mount options are listed in the mount.cifs manpage

Some people have also been getting hard to debug cifs errors and fixed them by installing keyutils. I can't say that's the case here, as the command line works and I don't see evidence of kerberos authentication, but you might try that.

[Morbius1 (morbius1)]

What is missing from your description is what happens after your system has finished rebooting.

Does the share mount when you issue one of the following commands:

sudo mount -a

Or:

sudo mount /mnt/server_e

Both of those commands will reference the fstab declaration.

If it does this may not be a "bug" in cifs itself but in the boot process where the line in fstab is being executed before the network stack is operational on the client so it cannot connect to any remote share - until after the entire boot process is complete.

[Daniel Essin (essin)]

What happens is that nothing changes. the share that won't mount with "mount -a" does not mount during thhe boot.

On Wed, Sep 23, 2020, at 10:31 AM, Morbius1 wrote:
> What is missing from your description is what happens after your system
> has finished rebooting.
>
> Does the share mount when you issue one of the following commands:
>
> sudo mount -a
>
> Or:
>
> sudo mount /mnt/server_e
>
> Both of those commands will reference the fstab declaration.
>
> If it does this may not be a "bug" in cifs itself but in the boot
> process where the line in fstab is being executed before the network
> stack is operational on the client so it cannot connect to any remote
> share - until after the entire boot process is complete.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1896699
>
> Title:
> Mounting a share in fstab fails with BAD_NETWORK_NAME
>
> Status in cifs-utils package in Ubuntu:
> Incomplete
>
> Bug description:
> The following command works:
> mount -t cifs //192.168.1.200/Drive_E /mnt/server_e -o
> credentials=/root/.smbcredentials_server
>
> The following fstab entry fails:
> //server/Server_E /mnt/server_e cifs
> uid=0,credentials=/root/.smbcredentials_server,file_mode=0755,dir_mode=0755,vers=2.1,sec=ntlmssp 0 0
>
> There is an entry in hosts for server. It also fails with
> //192.168.1.200/Server_E
> Sometimes it says:
> 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.
> [ 2079.955734] CIFS VFS: BAD_NETWORK_NAME: \\192.168.1.200\Server_E
> CIFS VFS: cifs_mount failed w/return code = -2
>
> trying vers=1.0 and vers=3.0 makes no difference.
>
> There is no documentations of CIFS VFS error codes
> There is no documentation of how to specify the SMB dialect.
> People appear to have been having trouble with these things for at
> least the past 10 years.
>
> I never had a problem with this on debian.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 20.04
> Package: samba 2:4.11.6+dfsg-0ubuntu1.4
> ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55
> Uname: Linux 5.4.0-47-generic x86_64
> NonfreeKernelModules: nvidia_modeset nvidia ufsd
> ApportVersion: 2.20.11-0ubuntu27.8
> Architecture: amd64
> CIFSMounts: /root/smb4k/192.168.1.200/Drive_E //192.168.1.200/Drive_E
> cifs
> rw,relatime,vers=3.1.1,cache=strict,username=essin,domain=WORKGROUP,uid=0,forceuid,gid=0,forcegid,addr=192.168.1.200,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1
> CasperMD5CheckResult: skip
> CurrentDesktop: XFCE
> Date: Tue Sep 22 17:35:02 2020
> InstallationDate: Installed on 2020-09-18 (4 days ago)
> InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64
> (20200423)
> ProcEnviron:
> LANGUAGE=en_US
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
...

[Daniel Essin (essin)]

No, the share does not mount with either
sudo mount -a
Or:
sudo mount /mnt/server_e

On Wed, Sep 23, 2020, at 10:31 AM, Morbius1 wrote:
> What is missing from your description is what happens after your system
> has finished rebooting.
>
> Does the share mount when you issue one of the following commands:
>
> sudo mount -a
>
> Or:
>
> sudo mount /mnt/server_e
>
> Both of those commands will reference the fstab declaration.
>
> If it does this may not be a "bug" in cifs itself but in the boot
> process where the line in fstab is being executed before the network
> stack is operational on the client so it cannot connect to any remote
> share - until after the entire boot process is complete.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1896699
>
> Title:
> Mounting a share in fstab fails with BAD_NETWORK_NAME
>
> Status in cifs-utils package in Ubuntu:
> Incomplete
>
> Bug description:
> The following command works:
> mount -t cifs //192.168.1.200/Drive_E /mnt/server_e -o
> credentials=/root/.smbcredentials_server
>
> The following fstab entry fails:
> //server/Server_E /mnt/server_e cifs
> uid=0,credentials=/root/.smbcredentials_server,file_mode=0755,dir_mode=0755,vers=2.1,sec=ntlmssp 0 0
>
> There is an entry in hosts for server. It also fails with
> //192.168.1.200/Server_E
> Sometimes it says:
> 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.
> [ 2079.955734] CIFS VFS: BAD_NETWORK_NAME: \\192.168.1.200\Server_E
> CIFS VFS: cifs_mount failed w/return code = -2
>
> trying vers=1.0 and vers=3.0 makes no difference.
>
> There is no documentations of CIFS VFS error codes
> There is no documentation of how to specify the SMB dialect.
> People appear to have been having trouble with these things for at
> least the past 10 years.
>
> I never had a problem with this on debian.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 20.04
> Package: samba 2:4.11.6+dfsg-0ubuntu1.4
> ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55
> Uname: Linux 5.4.0-47-generic x86_64
> NonfreeKernelModules: nvidia_modeset nvidia ufsd
> ApportVersion: 2.20.11-0ubuntu27.8
> Architecture: amd64
> CIFSMounts: /root/smb4k/192.168.1.200/Drive_E //192.168.1.200/Drive_E
> cifs
> rw,relatime,vers=3.1.1,cache=strict,username=essin,domain=WORKGROUP,uid=0,forceuid,gid=0,forcegid,addr=192.168.1.200,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1
> CasperMD5CheckResult: skip
> CurrentDesktop: XFCE
> Date: Tue Sep 22 17:35:02 2020
> InstallationDate: Installed on 2020-09-18 (4 days ago)
> InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64
> (20200423)
> ProcEnviron:
> LANGUAGE=en_US
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SambaClientRegression: Ye...

[Launchpad Janitor (janitor)]

[Expired for cifs-utils (Ubuntu) because there has been no activity for 60 days.]