Learn Samba - Client Access: Linux & Windows

#Introduction

Your shares are alive (episodes 3-4) and the users are registered (episode 5). Now it's time to actually use them from the client side — and this is the moment real users feel. In episode 6 we cover access from two worlds: Linux clients with mount -t cifs and smbclient, and Windows clients with the UNC \\server\share, credentials, and network discovery. Being able to explain both sides is the core value of a Samba administrator.

#Access from Linux

#smbclient: The Command-Line Client

smbclient is the fastest way to test connectivity without mounting. To browse shares on a server:

List shares on a server

smbclient -L //fileserver -U arman

To enter a share interactively (similar to ftp):

Enter a share via smbclient

smbclient //fileserver/data -U arman

Inside the smb: \> prompt you have commands like ls, cd, get, put, mkdir, and exit. It's also the most-used debugging tool in episode 16 — if smbclient fails, connections from other applications will almost certainly fail too.

#mount -t cifs: A Permanent Mount

For local-folder-like access, mount the share onto a directory. Install the CIFS client first:

Install cifs-utils

sudo apt install -y cifs-utils

Then mount with the right identity:

Mount a CIFS share

sudo mount -t cifs //fileserver/data /mnt/data \
  -o username=arman,uid=1000,gid=1000,vers=3.1.1

Breaking down the important options:

username=arman: the Samba user used for authentication.
uid=1000,gid=1000: mounted files will appear owned by these local UID/GIDs — determines permissions on the client side (remember the permission layers from episode 4).
vers=3.1.1: force the SMB3.1.1 dialect — avoids insecure older versions and the "mount legacy version" warning.

Check the result:

Verify the mount

df -h /mnt/data
ls -la /mnt/data

#Permanent Mount in /etc/fstab

To survive reboots, write it into /etc/fstab. Since fstab is read before the network is ready, add the _netdev,x-systemd.automount options:

/etc/fstab — Samba mount

//fileserver/data  /mnt/data  cifs  username=arman,uid=1000,gid=1000,credentials=/etc/samba/creds-data,vers=3.1.1,_netdev,x-systemd.automount,noatime  0  0

Note the use of credentials=/etc/samba/creds-data — a file holding the username/password, set to chmod 600, so the password isn't visible in fstab, which anyone can read:

Credentials file

sudo tee /etc/samba/creds-data > /dev/null <<'EOF'
username=arman
password=S3curePass!
EOF
sudo chmod 600 /etc/samba/creds-data

Tip

x-systemd.automount makes the mount happen at first access, not at boot — so a Samba server that isn't ready yet won't hang the client's boot. This is a must-use pattern for CIFS mounts on both workstations and servers. For production, also consider an explicit vers=3.1.1 option and sec=krb5 if you use winbind (episode 10).

#Access from Windows

#UNC: \server\share

Windows clients access shares via the UNC path: \\fileserver\data. Press Win+R, type the path, then log in with Samba credentials when prompted. You can also map it to a drive letter: net use Z: \\fileserver\data or via Map network drive in Explorer.

#Storing Credentials

To avoid repeated prompts, store the credentials:

Store credentials on Windows

cmdkey /add:fileserver /user:arman /pass:Password
net use Z: \\fileserver\data

cmdkey stores the credential in Credential Manager; after that, net use Z: succeeds without a prompt. This is also the right way to automate via scripts on Windows.

#Network Discovery

By default Windows Explorer tries to find servers via Network Discovery. Note: this feature depends on several mechanisms — DNS, WS-Discovery (port 5357), and for Samba sometimes NetBIOS (nmbd). If \\fileserver doesn't show up under "Network", that doesn't mean Samba is broken; check in this order:

Can you ping fileserver? (DNS at the hostname)
Can you access \\fileserver directly? (UNC, not browsing)
Is Windows discovery enabled? (Settings → Network → Advanced)

The most reliable pattern in production: always access via UNC/DNS, not by relying on the Network icon — because discovery uses broadcast that doesn't cross VLANs/subnets and is influenced by many things outside Samba.

#Common Pitfalls

"Path not found" on Windows: often a DNS problem, not a share problem. Check nslookup fileserver from the Windows client.
cifs mount "Permission denied" at fstab time: the credentials file isn't readable (permissions or wrong path) or uid/gid don't match.
Locked files / Transport endpoint is not connected: a CIFS mount left idle or with a dropped connection; unmount and remount, or use x-systemd.automount.
Windows 10/11 discovery fails: check that nmbd is running and the client firewall allows it; but prioritize DNS + direct UNC.

Warning

Never put an SMB password in plain text on a command line that gets recorded in shell history (history), especially with -o password=.... Use a credentials file with chmod 600, or let the interactive prompt handle it. This small habit prevents credentials from leaking to anyone who can read shell history or process logs.

#Closing

Key takeaways:

smbclient -L for browsing, smbclient //host/share for interactive access.
mount -t cifs ... -o username=,uid=,gid=,vers=3.1.1 for manual mounts and fstab with credentials + x-systemd.automount.
Windows uses the UNC \\server\share; store credentials with cmdkey.
Network discovery doesn't always find the server — prioritize access via DNS/UNC.
Never put raw passwords on the command line.

In episode 7 next, we'll cover print sharing: sharing Linux printers to the Windows network via the [printers] section, the CUPS backend, Windows printer drivers, and verification with smbclient -L localhost and a test print. From files to printing — Samba's capabilities keep growing!