How to troubleshoot CIFS mount errors on Linux

When a Linux CIFS mount fails, the visible mount.cifs error can point at the wrong layer. A bad share name, stale credential file, blocked SMB connection, unsupported protocol version, or missing local mount point can all surface as a short numeric error, so the fix starts by matching the mount failure with the SMB client check and the kernel CIFS message.

Separate the check into three surfaces before changing options. smbclient proves whether the server can be reached, whether the account can authenticate, and which shares the server advertises; mount.cifs proves whether the kernel client can attach that share; dmesg shows the kernel-side reason when the mount helper reports only a generic error.

The examples use files.example.net, the share team, and a protected credentials file at /etc/samba/credentials/team-share. Replace those values with the failing server, share, mount point, and credential file from the original command so the retest follows the same path that failed.

1. Confirm that the local mount point exists.

   $ ls -ld /mnt/team
   drwxr-xr-x 2 root root 4096 Jun 16 09:15 /mnt/team

   If the directory is missing, create it with sudo install -d -m 0755 /mnt/team before diagnosing the SMB side. A missing local path can produce a misleading mount error before the client reaches the server.

2. Reproduce the failing CIFS mount command.

   $ sudo mount -t cifs //files.example.net/projects /mnt/team -o credentials=/etc/samba/credentials/team-share,vers=3.1.1
   mount error(2): No such file or directory
   Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

   Keep the failed server name, share name, mount point, credential file, and vers option visible while troubleshooting. Changing several of them at once can hide the layer that actually failed.

3. Read the recent CIFS kernel messages for the same failure.

   $ sudo dmesg --level=err,warn
   ##### snipped #####
   [165656.449803] CIFS: VFS: BAD_NETWORK_NAME: \\files.example.net\projects
   [165656.451510] CIFS: VFS: cifs_mount failed w/return code = -2

   BAD_NETWORK_NAME means the server was reached, but the requested share name was not accepted. Authentication failures, protocol negotiation failures, and unreachable servers produce different CIFS messages, so match the log line to the mount attempt before editing options.

4. List the shares advertised by the SMB server.

   $ smbclient -L //files.example.net -U sguser -m SMB3
   Password for [WORKGROUP\sguser]:
   
   	Sharename       Type      Comment
   	---------       ----      -------
   	print$          Disk      Printer Drivers
   	team            Disk
   	IPC$            IPC       IPC Service (files server)
   SMB1 disabled -- no workgroup available

   If smbclient returns NT_STATUS_LOGON_FAILURE, fix the username, password, domain, or credential file before changing mount options. If it cannot connect at all, check name resolution, routing, and TCP port 445 reachability before retesting the mount.

5. Test the exact share name with smbclient.

   $ smbclient //files.example.net/team -U sguser -m SMB3 -c ls
   Password for [WORKGROUP\sguser]:
     .                                   D        0  Tue Jun 16 01:03:50 2026
     ..                                  D        0  Tue Jun 16 01:03:50 2026
     quarterly-plan.txt                  N       19  Tue Jun 16 09:16:01 2026
   
   		123530212 blocks of size 1024. 107394472 blocks available

   If the share browses with smbclient but still fails through mount.cifs, focus on the kernel mount options such as credentials, vers, sec, uid, gid, file_mode, and dir_mode instead of the server path.
   Related: How to force an SMB protocol version

6. Mount the corrected share path.

   $ sudo mount -t cifs //files.example.net/team /mnt/team -o credentials=/etc/samba/credentials/team-share,vers=3.1.1

   Keep passwords out of the command line and shell history. Use a root-readable credentials file with restrictive permissions when the command is reused or moved into /etc/fstab.
   Related: How to mount an SMB/CIFS share from fstab

7. Verify that the kernel mounted the expected CIFS source.

   $ findmnt --target /mnt/team --output TARGET,SOURCE,FSTYPE
   TARGET    SOURCE                   FSTYPE
   /mnt/team //files.example.net/team cifs

8. Check file access through the mounted path.

   $ ls /mnt/team
   quarterly-plan.txt

   If findmnt shows the mount but directory access returns Permission denied, the remaining issue is usually on the Samba account, share definition, filesystem permissions, or server security layer rather than the client mount syntax.
   Related: How to troubleshoot SMB share permission denied

9. Unmount the test mount if it was only created for troubleshooting.

   $ sudo umount /mnt/team