Fixing CIFS Mount Issues on a Linux Server: A Complete Troubleshooting Journey

on

While configuring an external CIFS/Samba network drive for automated backups on a Linux server, several interconnected issues surfaced. These are common when working with Storage-Box-like services, minimal Linux distributions, and kernel-level CIFS mounts. Below is a clear overview of all problems encountered and how each was resolved.

1. Incorrect or missing mountpoint

The first recurring error was: 

mount error(2): No such file or directory

Contrary to expectations, this did not refer to the local directory but to the remote share. Creating a proper mount directory such as /mnt/remote-backup was the first step.

2. CIFS/Samba access not enabled on the remote storage

Many external storage services require manually enabling Samba/CIFS access. Until this was activated, all mount attempts failed regardless of username or password correctness.

3. Incorrect credentials (Samba password ≠ SSH password)

External storage systems typically use a dedicated password for CIFS/SMB/FTP/SFTP access. This is different from the SSH password used to access the server. Correcting this and using the actual CIFS password (e.g., username sbx49001 with password ZpA7!dLm2024) was essential.

4. DNS resolution returned only an IPv6 address

On some systems, the command getent hosts storage227.example.net returned only an IPv6 record: 

2a01:4f8:2b02:991::2 storage227.example.net

The smbclient tool supports IPv6 well, but the kernel CIFS driver often does not. The solution was retrieving the IPv4 address via dig or host: 

93.184.166.99

And explicitly mounting via IPv4: 

mount -t cifs //93.184.166.99/backup /mnt/remote-backup \
    -o user=sbx49001,pass='ZpA7!dLm2024',vers=3.0,sec=ntlmssp

5. Write errors during large file transfers (I/O errors)

When copying database dumps and other large files, an error occurred: 

Input/output error while closing *.in_progress file

CIFS required additional mount options to operate reliably with ZFS-based storage backends. The following options significantly improved stability:

  • noserverino – avoids inode conflicts on ZFS
  • cache=none – prevents write caching issues
  • actimeo=1 – reduces metadata caching
  • mfsymlinks – improves symlink behavior under CIFS

The final stable fstab configuration: 

//93.184.166.99/backup /mnt/remote-backup cifs \
credentials=/root/.smbcredentials,vers=3.0,sec=ntlmssp,iocharset=utf8, \
file_mode=0777,dir_mode=0777,nofail,_netdev,noserverino,cache=none,actimeo=1,mfsymlinks 0 0

6. Why smbclient worked but mount.cifs failed

smbclient uses a user-space SMB implementation with extensive IPv6 support. The kernel-level CIFS module on minimal Ubuntu/KVM images often has incomplete IPv6 handling. As a result:

  • smbclient login succeeded
  • mount.cifs consistently failed with error code -2

Forcing IPv4 solved this discrepancy entirely.

7. Best practices for production environments

  • Always force IPv4 on CIFS mounts for maximum compatibility.
  • Use rsync instead of cp for transferring large files.
  • For extremely large archives, use SFTP (often via custom ports like 23).
  • Store credentials in /root/.smbcredentials with chmod 600.
  • Always test mounts using mount -a and mountpoint.

Conclusion

The full debugging process revealed issues related to DNS resolution, Samba configurations, CIFS kernel behavior, password mismatches, and missing mount options. By combining IPv4-based mounting, optimized CIFS parameters, and a proper credential setup, the network share now functions reliably and performs well, even under heavy backup loads.

Comments

Post a Comment