Testing Connectivity to an SMB NAS Share from the Command Line

When a NAS share suddenly becomes unavailable, it helps to test the connection layer by layer instead of jumping straight to mounting the share.

For an SMB/CIFS share, the most useful checks are:

1. IP connectivity
2. TCP port availability
3. SMB protocol connectivity
4. Authentication and share access
5. Actual mounting

Assume the following example configuration:

NAS IP:      192.168.1.10
Share name:  data
Username:    myuser

Test Basic Network Connectivity

The simplest test is ping:

ping 192.168.1.10

This confirms that the NAS is reachable on the network.

However, a failed ping does not necessarily mean that SMB is unavailable. ICMP may be blocked by a firewall while TCP connections are still allowed.

For this reason, ping should only be considered the first test.

Test Whether SMB Port 445 Is Reachable

Modern SMB normally uses TCP port 445.

Windows

PowerShell provides a convenient test:

Test-NetConnection 192.168.1.10 -Port 445

The most important result is:

TcpTestSucceeded : True

If this value is True, the TCP connection to the NAS on port 445 can be established.

This command is particularly useful when troubleshooting firewall rules.

Linux

On Linux, nc can be used:

nc -zv 192.168.1.10 445

Depending on the installed tools, telnet can also be used:

telnet 192.168.1.10 445

These checks verify that routing and firewall rules allow traffic to the SMB service.

Test SMB with smbclient

A successful TCP connection does not yet prove that SMB itself works.

The smbclient tool provides a much better end-to-end test.

To list the available shares:

smbclient -L //192.168.1.10 -U myuser

After entering the password, the server should return the available SMB shares.

This verifies several things at once:

• the NAS is reachable,
• TCP port 445 is accessible,
• SMB negotiation works,
• the SMB server responds,
• authentication works.

Connect to a Specific Share

To test a particular share:

smbclient //192.168.1.10/data -U myuser

If the connection succeeds, an interactive SMB prompt appears:

smb: \>

The contents of the share can then be listed with:

ls

This is one of the most useful SMB tests because it verifies not only connectivity, but also access permissions to the actual share.

Test a Real CIFS Mount

The final test is mounting the share exactly as a Linux system would normally use it.

First create a temporary mount point:

mkdir -p /mnt/nas-test

Then mount the SMB share:

mount -t cifs //192.168.1.10/data /mnt/nas-test \
    -o username=myuser

After entering the password, check the contents:

ls -la /mnt/nas-test

When finished, unmount it:

umount /mnt/nas-test

If this succeeds, the complete SMB path from the Linux host to the NAS is working.

Recommended Troubleshooting Order

For SMB problems, I usually test from the lowest network layer upward:

ping NAS
   ↓
TCP port 445 reachable?
   ↓
smbclient -L //NAS
   ↓
smbclient //NAS/share
   ↓
mount -t cifs ...

Each step eliminates another class of possible problems.

For example:

This approach makes it much easier to determine whether the problem is caused by networking, firewall rules, SMB configuration, authentication, permissions, or the Linux mount configuration.

Additional Checks on Proxmox

When the NAS share is used as Proxmox storage, Proxmox provides additional commands that are useful after the basic SMB tests have succeeded.

Check the configured storage backends:

pvesm status

To ask Proxmox to query the available SMB shares directly:

pvesm scan cifs 192.168.1.10

If necessary, authentication parameters can also be supplied depending on the Proxmox version and configuration.

This gives a useful distinction:

• smbclient verifies SMB independently of Proxmox.
• pvesm verifies whether Proxmox itself can use the SMB server.

When troubleshooting a Proxmox NAS connection, testing with smbclient first therefore helps determine whether the problem belongs to the network/SMB layer or to the Proxmox storage configuration itself.