corvus

Time Machine over SMB in my homelab

· 6 min read

My Mac backs up to a Samba share in the homelab. The server is an unprivileged Debian LXC on Proxmox, and the files end up on the WD USB drive attached to the host. It has 512 MB of RAM, which is more than enough for this one job.

The setup is deliberately small. The Mac connects to the container over SMB, and Samba advertises the share as a Time Machine destination. The container writes through a bind mount to the host’s drive, so there is no separate network storage hop between Samba and the disk.

What happens during a backup

Samba is the software on the Debian container that speaks the SMB file-sharing protocol. SMB lets one computer access files and directories hosted by another as though they were on a mounted network volume. In this case, the Mac is the client and Samba is the server. The Mac opens a connection to the container’s SMB service on TCP port 445, authenticates as timemachine, and requests access to the TimeMachine share. Samba maps that share name to /srv/timemachine. smbd, Samba’s file-server process, handles those requests, checks the share permissions, and performs filesystem operations on behalf of that connection.

After I select the mounted share in Time Machine settings, macOS remembers it as a network backup destination and reconnects when it is time to back up or restore, as long as the Mac can reach the server. Time Machine normally runs hourly, though a backup is skipped if the Mac is asleep or the destination is unavailable. On an APFS Mac, it also creates local snapshots on the Mac’s internal disk. Those help recover recent changes while the network destination is away, but they are not another copy of the data.

When a backup runs, Time Machine compares the Mac’s current files with its backup history and transfers the data needed for the new backup using SMB file and directory operations. The first run sends the initial backup; later runs update the backup history with changes. If backup encryption is enabled, macOS protects the backup, while the Samba server’s job remains file storage and access control.

For a network destination, Time Machine stores its backup in a sparsebundle disk image on the share. Think of that as a disk image represented by a directory of smaller band files. macOS manages the image and its backup history; Samba receives SMB requests to create, read, update, and remove the files that make up that image. Samba is not deciding which Mac files belong in a backup. It provides the remote filesystem operations and advertises the Mac-specific capabilities Time Machine expects.

The write path is then:

flowchart TD
    mac["Time Machine on macOS"] -->|"SMB over TCP 445"| smbd["Samba smbd\nLXC 208"]
    smbd -->|"TimeMachine share"| sparsebundle["Sparsebundle\n/srv/timemachine/"]
    sparsebundle -->|"Proxmox mp0 bind mount"| drive["/mnt/wd/timemachine\nWD USB drive on corvus"]

The exact sparsebundle directory name is chosen by macOS. The path above shows the shape of the storage, not a filename I configured by hand.

The path to the disk

The service runs in LXC 208, timemachine, at 192.168.0.208. The backup directory lives on the Proxmox host at /mnt/wd/timemachine and is bind-mounted into the container at /srv/timemachine:

flowchart TD
    host["Proxmox host\n/mnt/wd/timemachine"] -->|"mp0 bind mount"| lxc["LXC 208\n/srv/timemachine"]
    lxc -->|"Samba share: TimeMachine"| mac["Mac\nsmb://192.168.0.208/TimeMachine"]

The LXC is unprivileged, so the host directory needs to be owned by UID and GID 100000. That ID maps to root inside the container. If the ownership is wrong, Samba can authenticate and the share can still fail when it tries to write backup data.

sudo chown 100000:100000 /mnt/wd/timemachine

The mount is declared in the container’s Proxmox config:

mp0: /mnt/wd/timemachine,mp=/srv/timemachine

That keeps Samba’s view simple: it only sees /srv/timemachine. The data itself stays on the host’s WD drive.

Samba needs to speak Mac

The important part of the Samba configuration is the fruit VFS module. It adds Apple-specific behavior to Samba’s SMB file server, including support for Mac metadata and the Time Machine capability advertisement. The share is also marked as a Time Machine target:

[global]
    workgroup = WORKGROUP
    server string = Homelab Time Machine
    log file = /var/log/samba/%m.log
    max log size = 50

    vfs objects = catia fruit streams_xattr
    fruit:metadata = stream
    fruit:model = MacSamba
    fruit:posix_rename = yes
    fruit:veto_appledouble = no
    fruit:wipe_intentionally_left_blank_rfork = yes
    fruit:delete_empty_adfiles = yes

[TimeMachine]
    path = /srv/timemachine
    valid users = timemachine
    read only = no
    browseable = yes
    vfs objects = catia fruit streams_xattr
    fruit:time machine = yes
    fruit:time machine max size = 2T

The fruit:time machine = yes setting tells compatible Mac clients that the share supports Time Machine. The other fruit settings handle Apple metadata and file behavior that a plain SMB share does not provide in the same way. streams_xattr stores named streams through extended attributes, and catia handles filename character mapping. The VFS modules sit between SMB requests and the normal filesystem calls Samba makes, translating Mac-specific details as needed.

Without fruit, the share might look like an ordinary writable network folder, but that is not enough for a reliable Time Machine destination. Samba’s Mac-specific support is part of the backup setup, not an optional polish step.

Connecting the Mac

In Finder, I use Go → Connect to Server (⌘K) and enter smb://192.168.0.208/TimeMachine. The share asks for the timemachine account; its password is stored in my vault. Then I choose the mounted share under System Settings → General → Time Machine → Add Backup Disk.

macOS offers to encrypt the backup when it is first set up. I recommend enabling that. The encryption password is stored in the Mac’s keychain.

There is no Traefik route or DNS record for this service. The Mac connects directly to the container’s LAN IP over SMB.

A small service with one important limit

The fruit:time machine max size = 2T setting tells Time Machine that the destination is about 2 TB, even though the attached WD drive is 10 TB. It limits the capacity Samba reports; it is not a hard filesystem quota. Samba estimates usage by counting sparsebundle band files, so other files placed in the same share would not count toward that estimate. The Time Machine directory is separate from the other data on the WD drive.

The arrangement is easy to understand: one LXC runs Samba, one bind mount points at the backup directory, and the Mac sees a normal Time Machine destination. The disk is still a single USB drive on the Proxmox host, though. The LXC makes the service convenient to run; it does not give the backup storage another copy or protect it from the drive failing.

Discussion