cifs mount an SMB3 only share


We have recently moved our network shares to an AWS FSx file server and ever since then I have been unable to mount it using cifs on our balena devices.

Trying a mount with:

mkdir /mnt/my-share
mount -t cifs -o username=test //<server_address>/<share_name>/ /mnt/my-share/

Always returns a mount error(2): No such file or directory. With the following kernel messages:

[347779.475853] CIFS: Attempting to mount //<server_address>/<share_name>/
[347779.546190] CIFS: VFS:  BAD_NETWORK_NAME: \\<server_address>\<share_name>
[347779.564867] CIFS: VFS: cifs_mount failed w/return code = -2

These might sound like a network issue but I am actually able to mount exactly the same share when I try some userspace tools like smbnetfs or smbclient.
Previously, when we were still working with our old self-hosted SMB share, we were able to make the mount work by explicitly specifying the SMB dialect with vers=1.0, however, that does not work anymore since AWS FSx doesn’t support SMB1.

The device in question is a generic Generic x86_64 machine running on balenaOS 2.95.12+rev1 and supervisor version 12.11.38

I had the suspicion that the used cifs kernel module doesnt support SMB3 since I cant see any SMB3 or SMB211 kernel config flags when running:

> zcat /proc/config.gz | grep CIFS
# CONFIG_CIFS_STATS2 is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_ROOT is not set

Unfortunately, an out-of-tree module installation does not seem to be an option since cifs is a built-in module now and as I am not even sure if I am following the right track I also didnt want to try and rebuild the kernel from source (also because I have no idea how linux and especially this yocto kernel that balena uses actually work :slight_smile: )

Has anyone else already encountered this problem and can suggest any workarounds?

Any idea is much appreciated!


PS: I cant use smbclient for my application since it doesnt allow to actually mount a network share and smbnetfs would in theory do the trick but unfortunately it runs extremely unstable and I sometimes need to retry transferring files for hours until they eventually make their way onto the network share.

Hi, sorry for the delayed response. The CONFIG_CIFS configuration option includes SMB3 so I doubt that has nothing to do with the problem (see Kconfig « cifs « fs - kernel/git/stable/linux.git - Linux kernel stable tree).

Do you get this error when using a DNS name or an IP address? Have you tried an IP address for the server?

mount -t cifs -o username=test //<server-ip-address>/<share_name> /mnt/my-share/

Hi, sorry forgot about this thread :slight_smile:

As you correctly suspected the issue was with the server ip and share name, unfortunately mount.cifs is a bit more picky than “net use” on windows.

In case someone else stumbles upon this in the future, our three pain points were:

  1. The server address needs to be either the correct IP address or the netbios name (the netbios name might differ from the hostname! And just pinging the hostname that you use for the mount on windows might deliver a different IP!)
  2. The “share name” may be different than the “shared folder’s name”!
  3. We were only able to establish the connection after omitting all domain infos ( username=test instead of username=DOMAIN/test and do not use argument domain=DOMAIN

The simplest way to figuring these values out is to connect a windows PC to the network share and then opening a powershell window with admin rights. Entering Get-SmbConnection will then list all connected SMB shares.

Now if you’re mounting the share with
mount -t cifs -o username=<user> //<server-address>/<share_name> /mnt/my-share/

Use the value in the column “ServerName” for <server-address> (if your DNS works reliably, otherwise ping “ServerName” to get its IP address and use that instead), the corresponding value in column “ShareName” for <share_name> and column “UserName” for <user> (only the part after the backslash)

Hope this helps!

Glad to hear you got it to the bottom of it, and thanks for the detailed follow-up! I’ll add some details to our internal knowledge base too so it might help even more folk in the future.

1 Like