How to Set Up Arch Linux as a Home Server: SSH, Samba, and Docker

There is a question that surfaces in every serious homelab community sooner or later: why would anyone choose Arch Linux -- a rolling-release distribution known for requiring manual intervention and constant attention -- as the operating system for a home server? The conventional wisdom points toward Debian, Ubuntu Server, or even TrueNAS. Stability, predictability, and long-term support are the words that dominate server discussions.

But the conventional wisdom misses something fundamental.

A home server is not a production data center. It is an extension of your technical mind -- a place where you learn by building, where every configuration decision teaches you something about the system running underneath. Arch Linux, more than any other distribution, forces that learning. And the knowledge you accumulate from building an Arch-based server translates directly into competence with every other Linux system you will ever touch.

This guide walks through the complete process of transforming a bare Arch Linux installation into a functional home server running SSH for remote administration, Samba for cross-platform file sharing, and Docker for containerized service deployment. More importantly, it explains what is actually happening at each layer -- the kernel mechanisms, the protocol negotiations, the security boundaries -- so that you understand not just the commands, but the architecture.

Why Arch Linux for a Server: The Informed Contrarian's Case

The ArchWiki FAQ states it plainly: it is the user who is ultimately responsible for the stability of their own rolling release system. The user decides when to upgrade and merges necessary changes when required. This philosophy, often cited as a weakness for server use, is actually a hidden strength when you understand how to work with it.

A rolling release model means you receive security patches the moment they are available in upstream projects. Debian Stable, by contrast, backports security fixes into older package versions -- a process that can introduce delays. The Arch Linux wiki notes that the distribution strives to maintain the latest stable release versions of its software as long as systemic package breakage can be reasonably avoided. For a home server sitting behind your router, this means you are running the most current version of OpenSSH, the most current Samba release with the latest CVE patches, and the most current Docker engine -- all the time.

The trade-off is real, however. Rolling releases require you to read the Arch Linux news page before updating, to understand what manual interventions might be required, and to maintain snapshots or backups that let you roll back if something breaks. On a home server that you are managing yourself, this is not just acceptable -- it is educational. Every update that requires intervention is a lesson in how Linux systems actually work.

The practical mitigation strategy is straightforward. Install the linux-lts kernel alongside the standard kernel. This gives you a fallback boot option that receives fewer, more conservative updates while still keeping your userland packages current. Combined with a filesystem like Btrfs that supports atomic snapshots, you can update fearlessly, knowing that a rollback is always one command away.

Btrfs Snapshots: Atomic Rollback Protection

If you run Arch Linux as a rolling release on a server, filesystem-level rollback is your safety net. Btrfs snapshots let you revert the system state quickly after an update regression, misconfiguration, or accidental deletion.

Assumption: root is on Btrfs. If you are installing fresh, create subvolumes for / and /home (commonly @ and @home) and mount using subvol= so snapshots can be managed cleanly.

# Example (during install, when /mnt is your target root)
btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home

# Example fstab entries (replace UUID and options as needed)
# UUID=<uuid>  /      btrfs  subvol=@,compress=zstd,noatime  0 0
# UUID=<uuid>  /home  btrfs  subvol=@home,compress=zstd,noatime  0 0

The most practical snapshot manager on Arch is Snapper. It provides point-in-time snapshots and an automated timeline (hourly/daily) when paired with systemd timers.

pacman -S snapper
snapper -c root create-config /

Enable automated timeline snapshots and cleanup:

systemctl enable --now snapper-timeline.timer
systemctl enable --now snapper-cleanup.timer

Create a manual snapshot before a risky change (kernel updates, major config edits):

snapper -c root create --description "pre-upgrade"
snapper -c root list

If a change breaks the system, Snapper can roll the root filesystem back:

snapper -c root rollback <SNAPSHOT_NUMBER>

Boot-level rollback: if you use GRUB, install grub-btrfs so snapshots can appear as boot menu entries. This is particularly useful when the system won't fully boot.

pacman -S grub-btrfs
systemctl enable --now grub-btrfs.path

Phase One: Hardening SSH -- Your Server's Front Door

SSH is the first service you configure on any server, and it is the one that attackers will probe most aggressively. Automated bots scan port 22 across the entire IPv4 address space continuously. The moment your server has a public-facing SSH port, it is under attack. Understanding the cryptographic and protocol-level defenses available to you is not optional -- it is the baseline.

Installing and Enabling the SSH Daemon

pacman -S openssh
systemctl enable --now sshd

The sshd service is managed by systemd, which means it benefits from socket activation, resource controls via cgroups, and structured logging via the journal. After enabling, confirm the service is running:

systemctl status sshd

Key-Based Authentication with Ed25519

Password authentication over SSH is a liability. No matter how strong your password is, it exists in a space that can be brute-forced. SSH key authentication operates on a fundamentally different model: asymmetric cryptography, where the private key never leaves your client machine and the server only ever sees the public half.

The Ed25519 algorithm, based on the Twisted Edwards curve, is the current standard for SSH key generation. A 256-bit Ed25519 key provides security roughly equivalent to a 3,000-bit RSA key, while producing dramatically shorter public key strings and faster authentication handshakes. The underlying Curve25519 was designed by Daniel J. Bernstein specifically to resist timing-based side-channel attacks, a threat model that older algorithms like ECDSA handle poorly when implemented without constant-time arithmetic.

Generate your key pair on your client machine -- never on the server:

ssh-keygen -t ed25519 -f ~/.ssh/homeserver_ed25519 -C "yourname@homeserver"

The -C flag adds a comment that helps you identify the key later. The -f flag specifies a custom filename, which is important if you maintain separate keys for separate servers -- a practice you should adopt. Copy the public key to the server:

ssh-copy-id -i ~/.ssh/homeserver_ed25519 user@server-ip

Hardening the SSH Daemon Configuration

Edit /etc/ssh/sshd_config with the following changes. Each directive addresses a specific attack surface:

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowUsers yourusername
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
LogLevel VERBOSE

Port 2222 -- Moving SSH off port 22 does not provide real security against a determined attacker, but it eliminates the vast majority of automated scanning traffic. Bot networks target port 22 because it is the default; changing the port is noise reduction, not a security boundary.

PermitRootLogin no -- If an attacker compromises your SSH authentication, they land as an unprivileged user who must then escalate to root. This additional step gives you detection time and limits the blast radius.

PasswordAuthentication no -- This single directive eliminates the entire category of brute-force password attacks. The server will not even accept password-based authentication attempts. Combined with AuthenticationMethods publickey, the only way in is with a valid private key.

MaxAuthTries 3 -- After three failed authentication attempts in a single connection, the server drops the session. This slows down any attack that somehow bypasses key-only enforcement.

ClientAliveInterval and ClientAliveCountMax -- The server sends a keepalive probe every 300 seconds. If two consecutive probes receive no response, the session is terminated. This prevents orphaned sessions from remaining open indefinitely -- an important hygiene measure, since an abandoned SSH session with an authenticated user is a target.

X11Forwarding, AllowTcpForwarding, AllowAgentForwarding -- Each of these features extends the SSH session's capability beyond simple shell access. On a headless server you do not need X11 display forwarding. TCP forwarding allows the SSH tunnel to be used as a proxy, which is convenient but also dangerous if the server is compromised. Agent forwarding exposes your private key to the remote machine's socket, meaning a compromised server could intercept your key. Disable all three unless you specifically need them.

AllowUsers yourusername -- Explicitly restricts which local accounts are allowed to authenticate over SSH. This prevents service accounts (for example, Samba-only users) from being used as SSH entry points even if credentials are created or misconfigured elsewhere.

After making changes, validate the configuration before restarting:

sshd -t

If this returns no output, the configuration is valid. Restart the daemon:

systemctl restart sshd

Deploying Fail2Ban for Rate Limiting

Even with password authentication disabled, failed connection attempts consume resources and clutter logs. Fail2Ban monitors authentication logs and dynamically creates firewall rules to ban IP addresses that exhibit malicious behavior.

pacman -S fail2ban

On Arch Linux, sshd logs exclusively to the systemd journal -- there is no /var/log/auth.log by default. You must configure Fail2Ban to read from the journal using backend = systemd rather than a file-based logpath. Create /etc/fail2ban/jail.d/sshd.local:

[sshd]
enabled = true
port    = 2222
filter  = sshd
backend = systemd
maxretry = 3
bantime  = 3600
findtime = 600
ignoreip = 127.0.0.1/8 ::1

This configuration bans any IP that fails three authentication attempts within a ten-minute window, blocking it for one hour. Enable the service:

systemctl enable --now fail2ban

Verify the jail is active and reading journal events:

fail2ban-client status sshd

The output should show Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd, confirming journal-based log monitoring is working correctly.

Firewall Configuration with nftables

Arch Linux ships with nftables as the modern replacement for iptables. Create a basic server firewall:

pacman -S nftables

Edit /etc/nftables.conf:

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        ct state established,related accept
        iif lo accept

        # SSH (choose your port)
        tcp dport 2222 accept

        # Samba (restrict to local subnet)
        ip saddr 192.168.0.0/16 tcp dport 445 accept

        counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

The default input policy is drop, meaning any traffic not explicitly allowed is silently discarded. The ct state established,related rule allows return traffic for connections your server initiated, which is essential for package downloads and DNS resolution. Enable it:

systemctl enable --now nftables

Phase Two: Samba -- File Sharing That Speaks Every Platform's Language

Samba implements the Server Message Block (SMB) protocol, which is the native file-sharing protocol for Windows, is natively supported on macOS, and can be mounted on any Linux client. For a home server that needs to serve files to a mix of devices -- Windows desktops, MacBooks, Linux workstations, and even smart TVs -- Samba is the pragmatic choice.

What Happens During an SMB Connection

When a client connects to your Samba server, an intricate protocol negotiation takes place before a single file byte is transferred. The client sends a Negotiate Protocol Request that advertises which SMB dialects it supports. The server responds with the highest mutually supported version. On a modern network, this should be SMB3 or higher, which brings critical security features: transport encryption, secure dialect negotiation to prevent downgrade attacks, and integrity verification via pre-authentication hashing.

Native SMB transport encryption became available in SMB version 3.0, supported by Windows 8 and newer, Windows Server 2012 and newer, and smbclient from Samba 4.1 onward (source: samba.org, smb.conf manual page). Enforcing SMB3 as your minimum protocol version ensures that every connection to your server is encrypted in transit -- without needing a VPN or separate TLS layer.

Installation and User Configuration

pacman -S samba

Samba maintains its own password database, separate from the Linux system passwords. However, every Samba user must also exist as a Linux system user. This dual requirement exists because Samba uses Linux filesystem permissions for access control:

useradd -M -s /usr/bin/nologin sambauser
smbpasswd -a sambauser

The -M flag prevents creating a home directory (unnecessary for a file-sharing account), and -s /usr/bin/nologin prevents the account from being used for interactive shell access. The smbpasswd -a command adds the user to Samba's tdbsam database, which stores NTLM hashes used during SMB authentication.

Configuring /etc/samba/smb.conf

[global]
    workgroup = HOMELAB
    server string = Arch Home Server
    security = user
    map to guest = never

    # Protocol enforcement
    server min protocol = SMB3
    server max protocol = SMB3_11

    # Encryption and signing
    smb encrypt = required
    server signing = mandatory

    # Performance tuning
    use sendfile = yes
    server multi channel support = yes

    # Access control
    hosts allow = 192.168.0.0/16 127.0.0.1
    hosts deny = 0.0.0.0/0

    # Logging
    log file = /var/log/samba/log.%m
    max log size = 1000
    log level = 1 auth:3

[documents]
    path = /srv/samba/documents
    valid users = sambauser
    read only = no
    create mask = 0664
    directory mask = 0775
    force user = sambauser

[media]
    path = /srv/samba/media
    valid users = sambauser
    read only = yes
    browsable = yes

server min protocol = SMB3 -- This refuses connections from any client that cannot negotiate SMB3 or higher. As the Arch Wiki notes, you should enforce SMB3 when all clients are running Windows 10 and later. This single directive eliminates an entire category of downgrade attacks and ensures all connections are encryption-capable.

smb encrypt = required -- All data in transit is encrypted. Setting this to required globally turns on data encryption for all sessions and share connections, and clients that do not support encryption are denied access (source: samba.org, smb.conf manual page). This is the right setting for a home network where all your devices are modern.

server signing = mandatory -- Every SMB packet is cryptographically signed, preventing man-in-the-middle tampering. Combined with encryption, this provides both confidentiality and integrity.

Keep in mind: when smb encrypt = required is enabled, the session already has strong confidentiality and integrity properties. Many administrators still enforce signing for policy consistency and explicit integrity guarantees; it is safe to keep both enabled as long as clients support the negotiated settings.

map to guest = never -- This prevents any anonymous or failed authentication from being silently mapped to a guest account. If credentials are wrong, the connection is refused.

Performance tuning note (AIO settings) -- Older Samba tuning guides often recommend aio read size and aio write size to force asynchronous I/O behavior. On modern Samba 4.x and current kernels, async behavior is generally efficient by default, so these parameters are typically unnecessary unless you have benchmark evidence on your specific storage workload. A more modern SMB3-focused performance lever (when supported by clients) is enabling multichannel with server multi channel support = yes.

hosts allow and hosts deny -- Network-level access control that restricts Samba access to your local subnet. Even if a firewall rule is misconfigured, this directive prevents external connections.

Defense-in-depth: firewall rules control traffic at the packet layer, while hosts allow/hosts deny enforce access control at the application layer. If a firewall rule is accidentally broadened, Samba will still refuse connections that do not match the permitted host ranges.

Create the share directories and set permissions:

mkdir -p /srv/samba/{documents,media}
chown -R sambauser:sambauser /srv/samba
chmod -R 0775 /srv/samba

Enable the services:

systemctl enable --now smb nmb

The smb service handles file sharing. The nmb service handles NetBIOS name resolution, which allows Windows clients to find your server by hostname rather than IP address.

Testing the Configuration

Validate the configuration file:

testparm

This utility parses smb.conf and reports any errors or deprecated options. From a Linux client, test the connection:

smbclient -L //server-ip -U sambauser

From a Windows client, open File Explorer and navigate to \\server-ip\documents. You should be prompted for credentials.

Phase Three: Docker -- Containerized Services Without the Overhead

Docker on a home server transforms a single machine into a platform that can run dozens of isolated services simultaneously: a media server, a password manager, a DNS ad-blocker, a monitoring stack, a personal wiki -- each in its own container, with its own dependencies, isolated from the host and from each other.

Understanding Container Isolation at the Kernel Level

Docker containers are not virtual machines. They do not run a separate kernel. Instead, containers use Linux kernel features -- specifically namespaces and cgroups -- to create isolated environments that share the host kernel.

Namespaces provide isolation of system resources. A container gets its own PID namespace (it sees its processes starting from PID 1), its own network namespace (its own network interfaces, routing tables, and firewall rules), its own mount namespace (its own filesystem view), and its own user namespace (its own UID/GID mapping). The container process genuinely cannot see or interact with processes, networks, or filesystems outside its namespace boundaries.

Cgroups (control groups) provide resource limiting. You can restrict how much CPU, memory, and I/O bandwidth a container can consume. This prevents any single container from starving the host or other containers of resources. On modern systems running cgroup v2 with systemd, these limits are enforced at the kernel level and cannot be bypassed by the container process.

This architecture has a critical security implication: because all containers share the host kernel, a kernel vulnerability affects every container on the system. This is fundamentally different from virtual machines, where each VM runs its own kernel. For a home server, this trade-off is generally acceptable because the performance overhead is dramatically lower than full virtualization, but it means keeping your kernel updated is non-negotiable.

Installing Docker on Arch Linux

pacman -S docker docker-compose
systemctl enable --now docker

Add your user to the docker group to run containers without sudo:

usermod -aG docker yourusername

Log out and back in for the group change to take effect. Verify the installation:

docker info

Confirm that the storage driver is overlay2 (the modern default) and that the cgroup driver is systemd.

Rootless Docker: The Security-Conscious Approach

Standard Docker runs the daemon as root, which means any container escape vulnerability potentially gives an attacker root access to the host. Docker's rootless mode addresses this by running both the daemon and containers inside a user namespace, where root inside the container maps to an unprivileged user on the host.

The Docker documentation explains that rootless mode executes the Docker daemon and containers inside a user namespace. Unlike userns-remap mode -- where the daemon still runs with root privileges -- rootless mode runs both the daemon and the containers without any root privileges on the host.

Setting up rootless mode requires newuidmap and newgidmap from the shadow package (already installed on a standard Arch system), plus fuse-overlayfs:

pacman -S fuse-overlayfs
echo "yourusername:100000:65536" | sudo tee -a /etc/subuid
echo "yourusername:100000:65536" | sudo tee -a /etc/subgid
dockerd-rootless-setuptool.sh install

# Allow user services to run without an active login session
loginctl enable-linger yourusername

# Check the rootless daemon (user unit)
systemctl --user status docker

# If you need a shell to talk to the user daemon:
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

The /etc/subuid and /etc/subgid entries allocate a range of 65,536 subordinate UIDs and GIDs to your user. Inside the container, UID 0 (root) maps to UID 100000 on the host -- an unprivileged account that cannot modify host system files even if the container is compromised.

There are trade-offs. Rootless Docker cannot bind to privileged ports (below 1024) without additional configuration. Container networking performance may be slightly reduced because it goes through user-space networking (slirp4netns or pasta) rather than kernel-level bridging. For a home server where your services run on high ports behind a reverse proxy, these limitations are rarely relevant.

Docker Compose: Declarative Service Management

Docker Compose allows you to define multi-container applications in a single YAML file. This is where Docker's real power for home servers becomes apparent. Note that the top-level version field is obsolete as of Compose V2 (deprecated since v2.25.0) and should be omitted. Here is an example stack that deploys three commonly self-hosted services:

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    ports:
      - "9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data

  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - vw_data:/data
    environment:
      - SIGNUPS_ALLOWED=false

  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - kuma_data:/app/data

volumes:
  portainer_data:
  vw_data:
  kuma_data:

Deploy the entire stack with:

docker compose up -d

Every service defined in this file gets its own isolated filesystem, its own network stack, and its own process tree. If Vaultwarden has a security vulnerability, the attacker is contained within that container's namespace -- they cannot reach the Portainer management interface or the Uptime Kuma monitoring data.

Volume Management and Backup Strategy

Docker volumes persist data outside the container's ephemeral filesystem. When you destroy and recreate a container (for an update, for instance), the volume remains intact. List your volumes:

docker volume ls

For backup, you can snapshot volumes by mounting them in a temporary container:

docker run --rm -v vw_data:/source -v /backup:/target \
    alpine tar czf /target/vaultwarden-backup.tar.gz -C /source .

docker compose stop vaultwarden
docker run --rm -v vw_data:/source -v /backup:/target alpine tar czf /target/vaultwarden-backup.tar.gz -C /source .
docker compose start vaultwarden

Automate this with a cron job or a systemd timer, and your containerized services become trivially recoverable.

Phase Four: Operational Hardening (Optional, Strongly Recommended)

After core services are online, harden the system operationally. These controls reduce persistence opportunities, improve observability, and make recovery predictable.

Persist systemd-journald Logs Across Reboots

mkdir -p /var/log/journal
systemctl restart systemd-journald

Persistent journaling ensures SSH, Fail2Ban, Samba, Docker, and kernel logs remain available after a reboot, which is essential for incident review.

Install and Enable auditd

pacman -S audit
systemctl enable --now auditd

auditd provides kernel-level audit events (process execution, permission changes, etc.) and is valuable for detecting suspicious system activity.

Disable Unused Services

systemctl list-unit-files --state=enabled
# Disable anything you do not explicitly need
# systemctl disable --now <unit>

Servers should only expose intentional functionality. Minimize enabled services and open ports.

Automatic Container Image Updates (Choose a Controlled Approach)

For a home server, you can either update manually (preferred for stability) or use an automated updater like Watchtower. If you automate, pin versions where possible and monitor changes.

docker run -d   --name watchtower   -v /var/run/docker.sock:/var/run/docker.sock   containrrr/watchtower   --cleanup --schedule "0 0 4 * * *" 

Expose Services Safely (Reverse Proxy + TLS)

If you expose Docker services outside your LAN, avoid direct port exposure. Use a reverse proxy (Caddy, Traefik, or Nginx), enforce TLS, and add authentication and rate-limiting. Keep SSH exposure minimal and consider VPN (WireGuard) rather than public SSH if feasible.

systemd Service Hardening (Advanced)

systemd can sandbox services to reduce post-exploitation capability. For example, you can harden sshd via an override:

systemctl edit sshd

[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

Apply cautiously and validate connectivity after hardening changes.

Bringing It All Together: The Architecture

What you have built at this point is a layered system where each layer has a specific security and functional purpose.

Layer 1: SSH provides your administrative access channel. Key-based authentication with Ed25519, non-standard port, strict daemon configuration, and Fail2Ban rate limiting create a hardened entry point. nftables provides network-level traffic filtering.

Layer 2: Samba provides file services to your local network. SMB3 encryption and mandatory signing protect data in transit. User-level authentication with the tdbsam backend and restricted host access ensure that only authorized devices on your local subnet can access shares.

Layer 3: Docker provides an application platform. Each service runs in its own namespace with its own resource limits. Rootless mode ensures that even a container escape does not yield host root access. Compose files provide declarative, version-controlled service definitions that make the entire stack reproducible.

The host operating system -- Arch Linux -- sits beneath all of this, providing the kernel, the package management, and the systemd service infrastructure that coordinates everything. Its rolling release model ensures that security patches propagate immediately, while the LTS kernel option provides a conservative fallback.

The Deeper Lesson

Building a home server on Arch Linux is not really about Arch Linux. It is about developing an internalized understanding of how Linux systems work -- the init system, the kernel namespaces, the cryptographic protocols, the filesystem permissions, the network stack. Every decision in this guide connects to a deeper architectural concept. SSH key authentication teaches you asymmetric cryptography. Samba configuration teaches you protocol negotiation and access control models. Docker teaches you kernel isolation primitives.

The home server you build today is a laboratory. The knowledge it generates is what makes you dangerous -- in the best possible sense of that word -- when you sit down in front of any Linux system, anywhere, for the rest of your career.

Start building.