Learn Linux - Network File Sharing (NFS & Samba) & DNS Basics

#Introduction

After episode 19 where we covered Linux Firewall Management — building default-deny policies with UFW, Firewalld, and iptables — you now know how to protect the communication paths between servers. But what's that secure communication for? In the real world, the main reason servers talk to each other is sharing data: a web server fetching files from a storage server, an application saving uploads to a file server, or a design team accessing shared assets from their laptops.

This is where file sharing comes in. Linux has two giant protocols for this: NFS (Network File System) for sharing files between Linux/Unix machines efficiently and transparently, and Samba which implements the SMB/CIFS protocol — the universal language understood by Windows, macOS, and NAS devices. Alongside that, we'll touch the basics of DNS connecting names and IP addresses — because file shares, email, and almost all network services run on top of correct name resolution.

In this episode 20, you'll practice three things: setting up an NFS server and mounting it on clients, preparing a Samba share for Windows/macOS clients, and understanding how Linux resolves names to IPs — complete with the traps that most often make a share "suddenly inaccessible".

#Main Discussion

#NFS: Sharing Files in the Linux Language

NFS lets a directory on one server be mounted as a local folder on another server. The most important thing to understand: NFS is based on RPC (Remote Procedure Call) — so it needs extra ports in the firewall, not just port 2049.

#Step 1 — Install on the Server

Debian / Ubuntu (server)RHEL / Rocky (server)

sudo apt update
sudo apt install nfs-kernel-server

sudo dnf install nfs-utils

#Step 2 — Define the Export

The directories you want to share are declared in /etc/exports. Each line contains the path, the allowed clients, and options in parentheses:

/srv/nfs/data   192.168.1.0/24(rw,sync,no_subtree_check)
/srv/nfs/backup 10.0.0.5(rw,sync,no_root_squash)
/home/shared    192.168.1.0/24(ro)

After editing /etc/exports, apply the configuration:

sudo exportfs -arv

sudo exportfs -v

#Step 3 — Open the Firewall

NFS needs several RPC services. On systemd systems, the NFS services open certain fixed ports:

UFW: NFS + RPC port rangeFirewalld: nfs, mountd, rpc-bind services

sudo ufw allow from 192.168.1.0/24 to any port nfs
sudo ufw allow from 192.168.1.0/24 to any port 111 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 111 proto udp

sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --reload

#Step 4 — Mount on the Client

On the client side, install the client package then mount the remote directory:

Debian / Ubuntu (client)RHEL / Rocky (client)

sudo apt install nfs-common

sudo dnf install nfs-utils

sudo mount -t nfs 192.168.1.10:/srv/nfs/data /mnt/data

192.168.1.10:/srv/nfs/data  /mnt/data  nfs  defaults,_netdev  0 0

df -hT | grep nfs

#Samba: Talking to Windows & macOS

A Linux server rarely lives alone; in an office, it's surrounded by Windows and macOS. Samba implements SMB/CIFS — the protocol all those platforms understand — so a folder on the Linux server appears like a normal network drive.

sudo apt install samba

sudo dnf install samba

#Configuring the Share in /etc/samba/smb.conf

[global]
   workgroup = WORKGROUP
   server string = File Server
   security = user
   map to guest = never
 
[backup]
   path = /srv/samba/backup
   browseable = yes
   valid users = admin
   read only = no

The [global] structure holds general settings, and each [share-name] block defines a share. The shared directory must exist and have the right permissions:

sudo mkdir -p /srv/samba/backup
sudo chown root:sambashare /srv/samba/backup
sudo chmod 770 /srv/samba/backup

#Validate, Create the Samba User, and Restart

testparm

sudo useradd -M -s /usr/sbin/nologin admin

sudo smbpasswd -a admin

sudo systemctl enable --now smbd
sudo systemctl restart smbd

Don't forget the firewall: open the SMB port (445/tcp) for internal-network clients, and enable the SMB services in systemd (smb/nmb).

From a Windows client: open \\192.168.1.10\backup in File Explorer. From macOS: Finder → Connect to Server → smb://192.168.1.10/backup. Both will ask for the credentials of the Samba user you just created.

Before moving to the client, test the share from inside the server itself with smbclient — this is the fastest way to separate "Samba is wrong" vs "the network is wrong":

sudo apt install smbclient        # or: sudo dnf install samba-client

smbclient -L 192.168.1.10 -U admin

smbclient //192.168.1.10/backup -U admin

If smbclient -L lists shares but login fails, the problem is almost certainly credentials (smbpasswd not set). If smbclient can't connect at all, check two things: the smbd service is running, and the firewall opens 445/tcp.

#NFS vs Samba: When to Use Which?

The rule of thumb: between Linux machines, use NFS. Facing desktop clients (Windows/macOS), use Samba. Both can coexist on the same server for different directories.

#DNS Basics: How Names Become Addresses

Everything you do on the network — NFS mounts, share access, SSH connections — depends on translating names to IPs. This is DNS resolution, and the order on a modern Linux system is:

1. /etc/hosts — a local static list checked first.
2. /etc/resolv.conf — points to a resolver (e.g. systemd-resolved, or a DNS server).
3. Remote DNS servers — the internet resolver hierarchy (the topic of episode 17 with dig).

127.0.0.1   localhost
192.168.1.10  nfs-server.lab
192.168.1.11  web-server.lab

nameserver 127.0.0.53
search lab.

To see the active resolver and the DNS servers used:

resolvectl status

getent hosts nfs-server.lab

getent hosts is the most honest way to test whether this name can be resolved by the system — because it follows the full order (hosts → DNS) exactly like applications. This is the first test when a mount or connection fails with "unknown host".

#BIND/named: When You Need Your Own DNS Server

For a lab or internal network, you might need to run BIND (named) — a DNS server that serves its own zones. It's a deep topic, but understanding the small map helps:

sudo apt install bind9

sudo systemctl status named

Zone configuration lives in /etc/bind/named.conf.local. Running full BIND requires understanding zone files, serials, and TTL — for most teams' needs, managed DNS (cloud provider) + /etc/hosts + systemd-resolved is enough. Don't build BIND before those three layers genuinely aren't sufficient.

#Case Study: One Lab Network That Talks to Itself

Let's combine everything into one real scenario. Two VMs: nfs-server.lab (192.168.1.10) and web-server.lab (192.168.1.11).

1. On nfs-server.lab, define the export in /etc/exports and run exportfs -arv.
2. Open the firewall: ufw allow from 192.168.1.0/24 to any port nfs (and the RPC ports).
3. On web-server.lab, add 192.168.1.10 nfs-server.lab to /etc/hosts.
4. Test the connection: showmount -e nfs-server.lab.
5. Mount: sudo mount -t nfs nfs-server.lab:/srv/nfs/data /var/www/data.
6. Sync the fstab with the _netdev option so the mount waits for the network at boot.
7. For Windows/macOS access on the same LAN, add a Samba share for the same folder (or a separate one) in smb.conf.

If steps 3 and 4 are skipped, you'll hit the trap we already discussed: the mount fails because the name isn't resolved — not because NFS is broken.

#Common Mistakes (Common Pitfalls)

1. A client without nfs-common/nfs-utils. mount: wrong fs type even though the server is healthy. Install the client package first.

2. The firewall only opens port 2049. NFS RPC uses dynamic ports; close the firewall and the mount still fails. Open the nfs, mountd, rpc-bind services (Firewalld) or ports 2049 + 111 (UFW).

3. Hostname not resolved. The mount uses nfs-server.lab but it's neither in /etc/hosts nor DNS. Always getent hosts <name> before blaming NFS.

4. Unnecessary no_root_squash. A client root becomes the server root — a huge security hole. Leave root_squash as the default.

5. Forgetting smbpasswd. The user exists in the system but the Samba password isn't set → share login fails. smbpasswd -a <user> is the often-missed step.

6. Wrong share directory permissions. The share is visible but not writable because the chmod/owner doesn't match. Make sure the directory is owned by the right group with appropriate permissions.

7. Editing /etc/resolv.conf manually. It's a symlink to systemd-resolved. Changes will be overwritten. Manage it via resolvectl or the network manager config.

#Conclusion

In this episode 20, you've learned to share files in three directions: setting up an NFS server with /etc/exports and mounting it on Linux clients, building a Samba share so server folders are accessible from Windows/macOS with smb.conf and smbpasswd, and understanding DNS basics — from /etc/hosts, /etc/resolv.conf, to systemd-resolved — which form the backbone of all name resolution.

Key points to take home:

• NFS for Linux-to-Linux; Samba for Windows/macOS desktop clients.
• NFS needs more than port 2049 — open the RPC services in the firewall.
• /etc/hosts and getent hosts are the first name-resolution debugging tools.
• testparm (Samba) and exportfs -arv (NFS) are mandatory validation rituals after changing configs.
• All file-sharing traps ultimately revolve around three things: packages, firewall, and name resolution.

In the next episode 21 we'll level up to deeper network management through the topic Advanced Networking & Packet Analysis. You'll learn to read traffic with tcpdump, combine interfaces with network bonding, separate virtual networks with VLANs, and get to know network namespaces — the skills that distinguish a network admin from a mere Linux user. See you there!