LPIC-2 File Sharing: Samba, NFS, and FTP

Advanced40 min7 steps

What you'll learn

Define and validate a Samba share in smb.conf, and explain why smbpasswd needs an existing system account
Export a directory over NFS and apply the change, reasoning about sync/async and root_squash
Lock down a vsftpd server by disabling anonymous access and chrooting users
Recognise the cleartext risk of plain FTP and diagnose the classic writable-chroot login failure

Why three protocols, not one
Frame Samba, NFS, and FTP as three answers to the same question, each tuned to a different client.
"Share a directory over the network" sounds like one job, but the right tool depends on who is asking.
- Samba speaks SMB/CIFS — the protocol Windows was born speaking. Reach for it when Windows machines (or mixed Windows/Linux offices) need to mount a drive.
- NFS is the native Unix-to-Unix file share. When both ends are Linux, NFS feels like a local disk and costs less overhead than SMB.
- FTP (here via vsftpd) isn't a mounted filesystem at all — it's a transfer protocol. Use it to push and pull files, not to live on the share.
Think of it like shipping a parcel: Samba is the international courier that fills out the customs forms Windows expects, NFS is the in-house mail cart that trusts everyone in the building, and FTP is the loading dock where you hand packages over one at a time.
Why it matters
LPIC-2 objective 209 tests all three because a real admin picks the protocol to fit the client, then secures it. The exam rewards knowing which config file each uses, which command applies a change, and the one security gotcha each carries. That triad — file, apply, gotcha — is the spine of this lesson.
Samba: define the share in smb.conf
Write a share section and prove it parses before you ever restart the daemon.
Samba's brain is a single file: `/etc/samba/smb.conf`. It has a [global] section for server-wide settings and one `[sharename]` section per exported directory. The trap is editing it and restarting blind — a single typo can stop the daemon from starting at all.
The fix is to validate first. testparm parses smb.conf exactly the way the daemon will, reports errors, and prints the configuration it understood — your spell-checker for Samba.
Example — not runnable on your lab box
```
$ testparm -s
```
```
Loaded services file OK.

[global]
	workgroup = WORKGROUP
	server string = Samba %v
	security = USER

[projects]
	path = /srv/samba/projects
	read only = No
	valid users = webadmin
```
-s
"Suppress prompt": dump the parsed config straight to stdout instead of pausing for you to press Enter.
`Loaded services file OK.` is the line you want — it means the syntax is valid. Below it, testparm echoes back the config as Samba understood it, including defaults it filled in. Seeing your [projects] share with read only = No and valid users = webadmin confirms the share is defined the way you intended.
A minimal share section to add under the file looks like this:
`
[projects]
path = /srv/samba/projects
valid users = webadmin
read only = no
`
path is the directory exported; valid users restricts who may connect; read only = no permits writes.
Validate, then reload — in that order
Always run testparm -s before systemctl reload smb. A clean testparm is cheap insurance against a typo that would otherwise leave the daemon dead and every Windows client locked out.
Check yourself
Which command parses smb.conf the way the daemon would and reports syntax errors before you restart Samba?
Samba: the smbpasswd trap and SELinux
Understand why Samba passwords ride on top of real system accounts, and what RHEL adds.
Samba keeps its own password database, separate from /etc/shadow. You add a user to it with smbpasswd -a. But here's the catch that bites almost everyone: `smbpasswd -a` only works for a user who already exists as a Linux system account. Samba maps each SMB login back to a real UID for filesystem permissions, so there has to be a UID to map to.
Think of the system account as the building pass and the Samba password as the door code for one room. You can't program a door code for a person who was never issued a building pass.
Example — not runnable on your lab box
```
$ sudo smbpasswd -a contractor
```
```
Failed to add entry for user contractor.
```
-a
Add the named user to the Samba password database (then prompt for their SMB password).
This failure is the classic gotcha: contractor has no entry in /etc/passwd, so Samba has no UID to attach the password to and refuses to create the entry. The error text is generic, which makes it confusing — the real cause is the missing system account.
Example — not runnable on your lab box
```
$ sudo useradd -M -s /usr/sbin/nologin contractor && sudo smbpasswd -a contractor
```
```
New SMB password:
Retype new SMB password:
Added user contractor.
```
-M
Don't create a home directory — this account exists only to own files on the share.
-s /usr/sbin/nologin
Deny an interactive login shell; the account is for Samba access, not SSH.
Create the system account first, then smbpasswd -a succeeds and prints Added user contractor.. Using -M and nologin is good hygiene: the user can authenticate to Samba but can't log into the host.
smbpasswd -a for a non-existent user
If smbpasswd -a fails with Failed to add entry for user, the user almost certainly has no system account yet. Run id <user> to check, then useradd them before retrying. Samba passwords are an overlay on real accounts — never a replacement for them.
On RHEL, SELinux is the next wall
Even with a perfect smb.conf, RHEL/CentOS clients may get "permission denied" because SELinux blocks Samba by default. Two knobs matter: the file context must allow Samba (chcon -t samba_share_t /srv/samba/projects, persisted with semanage fcontext), and the boolean `samba_export_all_rw` (set with setsebool -P samba_export_all_rw on) lets Samba write outside the default-labelled paths. A Samba share that works on Ubuntu but fails on RHEL is SELinux until proven otherwise.
Check yourself
smbpasswd -a alice fails with "Failed to add entry for user alice". What is the most likely cause?
NFS: export, apply, and root_squash
Export a directory, make the change take effect, and reason about the security and consistency knobs.
NFS exports are declared in `/etc/exports`, one line per shared directory:
`
/srv/nfs/data 192.0.2.0/24(rw,sync,root_squash)
`
That reads as: export /srv/nfs/data to clients in the 192.0.2.0/24 network, allow read-write, write synchronously, and squash remote root. Editing the file is not enough — the NFS server caches its export table, so you must tell it to re-read the file.
Example — not runnable on your lab box
```
$ sudo exportfs -ra
```
-r
Re-export: sync the kernel's in-memory export table with the current /etc/exports.
-a
Apply to all entries in /etc/exports, not just one.
Like many Unix tools, silence means success. After exportfs -ra, the kernel's export table matches your edited file. Verify with sudo exportfs -v, which prints each active export and its options.
Forgetting exportfs -ra
You edit /etc/exports, a client tries to mount, and gets access denied or permission denied — even though the line looks perfect. The cause is almost always that the running server is still using the old export table. sudo exportfs -ra reloads it. An /etc/exports edit that you never apply changes nothing.
Two pairs of options are exam favourites:
- `sync` vs `async` — sync makes the server confirm a write only after it's safely on disk; async replies before the data is durable. async is faster but risks data loss on a server crash. sync is the safe default.
- `root_squash` — maps a remote client's root (UID 0) to the unprivileged `nobody` user. Without it (no_root_squash), root on any client becomes root on your exported files — a serious privilege escalation across the network. Keep root_squash on.
On the client side, you mount an NFS share like any filesystem, but add the `_netdev` option in /etc/fstab:
`
192.0.2.10:/srv/nfs/data /mnt/data nfs _netdev,defaults 0 0
`
_netdev tells the system this mount depends on the network, so at boot it waits for networking to come up before trying — preventing a hang or failed mount on a share that isn't reachable yet.
Why it matters
root_squash exists because NFS historically trusts the client's UIDs. The server can't tell a legitimate root from an attacker who controls a client machine, so it defends itself by demoting remote root to nobody. Turning it off (no_root_squash) hands the keys to every client — only do it for tightly controlled cases like diskless boot, never for general shares.
Check yourself
You edited /etc/exports but the client still can't mount the share. Which command makes the new export take effect?
FTP with vsftpd: lock it down
Configure vsftpd for private use by disabling anonymous access and chrooting users.
vsftpd ("Very Secure FTP Daemon") is the standard FTP server on Linux, configured via `/etc/vsftpd/vsftpd.conf` (or /etc/vsftpd.conf on Debian). For a private server you want two things off the default and two things on:
- Disable anonymous login so random internet users can't connect.
- Allow local users to log in with their system accounts.
- Chroot each user so they're jailed to their home directory and can't wander the whole filesystem.
The relevant directives:
`
anonymous_enable=NO
local_enable=YES
chroot_local_user=YES
`
Example — not runnable on your lab box
```
$ grep -E 'anonymous_enable|local_enable|chroot_local_user' /etc/vsftpd/vsftpd.conf
```
```
anonymous_enable=NO
local_enable=YES
chroot_local_user=YES
```
-E
Extended regex, so the | alternation matches any of the three directive names in one pass.
Confirming the three key settings at a glance. `anonymous_enable=NO` shuts the public door, `local_enable=YES` lets real accounts in, and `chroot_local_user=YES` jails each of them to their home directory — the private-server posture in one grep.
Why it matters
Chrooting is the FTP equivalent of a hotel keycard that only opens your own room: a user can move around inside their home directory but the rest of the filesystem simply doesn't exist for them. Without it, a logged-in user could read /etc, browse other users' files, and map out the box.
Plain FTP is cleartext — prefer SFTP/FTPS
Classic FTP sends usernames, passwords, and file contents in the clear. Anyone sniffing the network sees them. For real use, prefer SFTP (file transfer over SSH — nothing extra to install if sshd is running) or FTPS (FTP wrapped in TLS). Treat plain vsftpd as a lab/legacy tool, not an internet-facing service.
Check yourself
Which vsftpd directive jails each logged-in local user to their own home directory?
The vsftpd writable-chroot gotcha
Diagnose and fix the single most common vsftpd login failure.
You set chroot_local_user=YES, restart vsftpd, the user enters correct credentials — and login fails immediately. The log or client shows:
`
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
`
This is the vsftpd gotcha, and it's a deliberate security check, not a bug. vsftpd refuses to chroot a user into a directory that the user can write to, because a writable chroot root can be abused to escape the jail. Since a user usually owns and can write their own home directory, the default chroot target trips this check.
Example — not runnable on your lab box
```
$ ls -ld /home/webadmin
```
```
drwxr-xr-x 2 webadmin webadmin 4096 Jun 23 11:40 /home/webadmin
```
-d
Show the directory itself, not its contents.
-l
Long format, so you can read the owner and the write bit.
webadmin owns this directory and has the w bit (rwx for the owner), so it's writable by the user being chrooted into it — exactly the condition vsftpd refuses. That ownership is what triggers the refusing to run with writable root error.
There are two standard fixes:
1. Make the chroot root non-writable by the user — e.g. sudo chmod a-w /home/webadmin, so the top directory is read-only and writes go into a sub-directory beneath it.
2. Allow the writable case explicitly by adding `allow_writeable_chroot=YES` to vsftpd.conf — this tells vsftpd you accept the risk and want it to proceed anyway.
Example — not runnable on your lab box
```
$ echo 'allow_writeable_chroot=YES' | sudo tee -a /etc/vsftpd/vsftpd.conf && sudo systemctl restart vsftpd
```
```
allow_writeable_chroot=YES
```
Appending allow_writeable_chroot=YES and restarting vsftpd lets the chrooted user log in even though their home is writable. tee -a appends the line (and echoes it back, which you see in the output); the restart reloads the config so the new directive takes effect. The cleaner alternative is option 1 — make the chroot root non-writable — which keeps vsftpd's protection in place.
Writable chroot breaks the login
If a chrooted vsftpd user can't log in and you see refusing to run with writable root inside chroot(), the chroot directory is writable by that user. Either strip the write bit from the chroot root or set allow_writeable_chroot=YES. Don't waste time re-checking the password — the credentials are fine; the directory permissions are the problem.
Check yourself
A chrooted vsftpd user can't log in and the error mentions "writable root inside chroot". What condition causes this?
Try it in your live terminal
Inspect the file-sharing state on the real sandbox to your right — read-only, safe to run.
You have a real root shell. The server software for these protocols may or may not be installed on this box — that's fine. The goal is to practice the inspection moves you'd run first on any file server: find the config, read it, and check what's actually exported. Each command below is read-only and degrades gracefully if the service is absent.
```
$ testparm -s 2>/dev/null | head || echo 'no samba'
```
Parse and summarise Samba's config if it's installed. 2>/dev/null hides the validation banner on stderr; head keeps it short; the || echo 'no samba' prints a friendly note if testparm isn't present. You're looking for share sections and Loaded services file OK..
Runnable in the netsvc-nfs-export room — that room’s setup plants the files it reads
```
$ cat /etc/exports 2>/dev/null || echo 'no exports'
```
Show the NFS export table source. If the file exists, read each line as path client(options) and check for root_squash and sync. If it doesn't, you'll see no exports — this box isn't an NFS server.
```
$ showmount -e localhost 2>/dev/null || true
```
Ask the local NFS server which directories it's actually exporting right now (the applied table, not just the file). || true keeps the step from erroring out if NFS isn't running. Compare this live view against /etc/exports — a mismatch is the tell-tale sign someone forgot exportfs -ra.

Recap

Pick the protocol by the client: Samba for Windows/SMB, NFS for Unix-to-Unix, FTP/vsftpd for transfers (and prefer SFTP/FTPS since plain FTP is cleartext).
Each protocol has a config file and a separate apply step — editing the file is never enough; you must validate (testparm) or reload (exportfs -ra, service restart).
Samba passwords ride on real system accounts: smbpasswd -a fails unless the user already exists, and on RHEL, SELinux booleans/context are the next wall.
NFS root_squash demotes remote root to nobody (keep it on); the vsftpd writable-chroot error is a security refusal, not a credential problem.

Protocol → config file → apply command
Protocol	Config file	Apply / validate	Signature gotcha
Samba (SMB/CIFS)	`/etc/samba/smb.conf`	`testparm -s`, then `systemctl reload smb`	`smbpasswd -a` needs an existing system user; SELinux on RHEL
NFS	`/etc/exports`	`exportfs -ra`	Forgetting to reload; `no_root_squash` exposes root
FTP (vsftpd)	`/etc/vsftpd/vsftpd.conf`	`systemctl restart vsftpd`	Writable chroot root: "refusing to run with writable root inside chroot()"

LPIC-2 File Sharing: Samba, NFS, and FTP

Why three protocols, not one

Samba: define the share in smb.conf

Samba: the smbpasswd trap and SELinux

NFS: export, apply, and root_squash

FTP with vsftpd: lock it down

The vsftpd writable-chroot gotcha

Try it in your live terminal