Time Machine Raspberry Pi NAS Samba: 6-Step Setup Guide

Q: Can I use a Raspberry Pi 3 for Time Machine backups?

Yes, but throughput is limited to 25-40 MB/s due to the shared USB bus. Initial large backups will take many hours. Pi 4 with USB 3.0 is significantly faster.

Q: Why does my Mac not see the Pi in Time Machine preferences?

Most common causes: Avahi not advertising _adisk._tcp, Pi and Mac on different subnets, or fruit module not loaded. Check with avahi-browse -t _adisk._tcp and testparm.

Q: What happens if the Pi loses power during a backup?

Time Machine usually repairs the sparsebundle automatically on the next backup. If not, use hdiutil verify and fsck_apfs. A UPS eliminates this risk.

Q: How do I restore from this backup if my Mac dies?

Boot into macOS Recovery, choose Restore from Time Machine Backup, connect to the network, select the Pi share, and enter the tmuser credentials.

Time Machine Raspberry Pi NAS Samba turns a Pi 4 or Pi 5 into a local network backup target for macOS using SMB3. macOS Big Sur and later support Time Machine over SMB natively. The Pi runs Samba with the fruit module enabled and Avahi advertising the share as a Time Machine destination. macOS discovers the share automatically and writes backups as a sparsebundle on the Pi’s external drive. No Apple hardware, no subscription, and no AFP required.

Last tested: Raspberry Pi OS Bookworm Lite 64-bit | March 3, 2026 | Raspberry Pi 4 Model B (4GB) | Samba 4.17 | macOS Sequoia 15.3

Key Takeaways

Time Machine over SMB requires macOS Big Sur (11) or later. Catalina and earlier used AFP, which Samba does not support in a way macOS accepts for Time Machine.
Samba requires the fruit module (vfs objects = catia fruit streams_xattr) and fruit:time machine = yes in the share section. Without these, macOS will not recognise the share as a valid Time Machine destination.
Avahi must be installed and configured to advertise the share over mDNS. Without it, the share does not appear automatically in Time Machine preferences. You can still connect manually by IP, but automatic discovery fails.
Format the backup drive as ext4. macOS writes backups to a sparsebundle, so the underlying Linux filesystem format does not matter to Time Machine.
Give each Mac its own Samba share or subdirectory. Two Macs writing to the same sparsebundle will corrupt the backup.
Use Ethernet. Time Machine backups over Wi-Fi work but are significantly slower and more prone to interruption on large initial backups.

Time Machine Raspberry Pi NAS Samba architecture diagram showing Mac connecting over SMB3 to Pi running Samba with fruit module writing to external USB drive

How Time Machine Raspberry Pi NAS Samba Works

Time Machine on macOS Big Sur and later connects to network backup destinations using SMB3. When the Mac discovers a Time Machine-compatible share, it creates a sparsebundle disk image on the share and mounts it as a virtual drive. All backup data is written inside the sparsebundle. The underlying storage on the Pi sees only a growing disk image file. It does not need to understand APFS or HFS+ because macOS manages those filesystems inside the sparsebundle.

Samba’s fruit module provides macOS-compatible SMB extensions. It handles the extended attribute storage that macOS expects, the resource fork handling that prevents file corruption, and the Time Machine advertisement that tells macOS this share is a valid backup destination. Without fruit, Samba presents a generic SMB share that macOS rejects for Time Machine use.

Hardware Requirements

Component	Minimum	Recommended
Raspberry Pi	Pi 3B+	Pi 4 (2GB+) or Pi 5
Backup storage	USB HDD	USB SSD via USB 3.0 port
OS storage	16GB microSD	USB SSD (separate from backup drive)
Network	Wi-Fi	Gigabit Ethernet
Power supply	5V/2.5A	Official Pi 4 adapter (5V/3A)

Pi 4 or Pi 5 with Gigabit Ethernet and USB 3.0 is the practical choice. Pi 3B+ works but its 300Mbps USB bus is shared between all USB ports and Ethernet, which limits backup throughput. Use the blue USB 3.0 ports on Pi 4 and Pi 5 for the backup drive. Power the drive from a powered USB hub or a self-powered enclosure. Drawing drive power from the Pi’s USB ports risks undervoltage mid-backup. For OS storage, see Booting Raspberry Pi from USB SSD and Preventing SD Card Corruption on Raspberry Pi.

Step 1: Prepare Raspberry Pi OS

Flash Raspberry Pi OS Bookworm Lite 64-bit using Raspberry Pi Imager. In Imager’s advanced settings, configure hostname (e.g. timepi), enable SSH, set credentials, and add Wi-Fi if needed. After first boot:

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Set the hostname and verify NTP sync. macOS rejects connections to servers with significant clock drift:

sudo hostnamectl set-hostname timepi
timedatectl status
# Confirm: System clock synchronized: yes

Expected result: SSH connects to timepi.local. timedatectl shows the clock as synchronised.

Step 2: Format and Mount the Backup Drive

# Identify the backup drive
lsblk
sudo fdisk -l /dev/sda

# Create a new partition table and ext4 partition
sudo parted /dev/sda --script mklabel gpt
sudo parted /dev/sda --script mkpart primary ext4 0% 100%
sudo mkfs.ext4 -L timemachine /dev/sda1

# Get the UUID for fstab
sudo blkid /dev/sda1

Create the mount point and add the drive to /etc/fstab for automatic mounting on boot:

sudo mkdir -p /mnt/timemachine

# Add to /etc/fstab (replace UUID with your actual drive UUID)
echo 'UUID=your-drive-uuid  /mnt/timemachine  ext4  defaults,noatime  0  2' | sudo tee -a /etc/fstab

# Test the mount
sudo mount -a
df -h /mnt/timemachine

Expected result: df -h /mnt/timemachine shows the drive mounted with the expected capacity. The mount survives a reboot.

Step 3: Create the Samba Backup User

# Create a dedicated system user for Time Machine backups
sudo adduser --system --group tmuser

# Create the backup directory and set ownership
sudo mkdir -p /mnt/timemachine/backups
sudo chown tmuser:tmuser /mnt/timemachine/backups
sudo chmod 770 /mnt/timemachine/backups

# Add tmuser to Samba and set a password
# (This password is what macOS uses to connect)
sudo smbpasswd -a tmuser

Expected result: sudo pdbedit -L lists tmuser as a Samba user.

Step 4: Install and Configure Samba

sudo apt install samba -y

Back up the default config and replace it with a clean macOS-compatible configuration:

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
sudo nano /etc/samba/smb.conf

Replace the contents with the following. The fruit module settings in the [global] section must be present. They cannot be set only in the share section:

[global]
   workgroup = WORKGROUP
   server string = Raspberry Pi Time Machine
   server role = standalone server
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file

   # macOS compatibility
   min protocol = SMB2
   ea support = yes

   # fruit module -- required for Time Machine and macOS extended attributes
   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

   # Performance
   socket options = TCP_NODELAY IPTOS_LOWDELAY
   read raw = yes
   write raw = yes

[TimeMachine]
   path = /mnt/timemachine/backups
   valid users = tmuser
   read only = no
   browseable = yes
   create mask = 0600
   directory mask = 0700

   # Time Machine specific
   fruit:time machine = yes
   fruit:time machine max size = 500G

The fruit:time machine max size setting limits how large the sparsebundle can grow. Set it to roughly 2 to 3 times the used space on the Mac being backed up. If you have multiple Macs, add a separate share section for each.

Validate the configuration and restart Samba:

# Validate smb.conf syntax
testparm

sudo systemctl restart smbd nmbd
sudo systemctl enable smbd nmbd

Expected result: testparm reports no errors. systemctl status smbd shows the service as active.

Step 5: Configure Avahi for Time Machine Discovery

Avahi broadcasts the share over mDNS (Bonjour) so macOS discovers it automatically in Time Machine preferences. Without Avahi, you can still connect manually by entering the Pi’s IP in the Time Machine “Add Backup Disk” dialog, but automatic discovery will not work.

sudo apt install avahi-daemon -y
sudo systemctl enable --now avahi-daemon

Create a service file that advertises the Time Machine share:

sudo nano /etc/avahi/services/timemachine.service

Paste the following:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">%h</name>
  <service>
    <type>_smb._tcp</type>
    <port>445</port>
  </service>
  <service>
    <type>_adisk._tcp</type>
    <port>9</port>
    <txt-record>sys=waMa=0,adVF=0x100</txt-record>
    <txt-record>dk0=adVN=TimeMachine,adVF=0x82</txt-record>
  </service>
</service-group>

sudo systemctl restart avahi-daemon

Expected result: On the Mac, open Time Machine preferences and click “Add Backup Disk.” The Pi should appear as a network location with the share name “TimeMachine.” If it does not appear within 30 seconds, see the troubleshooting section.

Step 6: Connect from macOS and Start Backup

On the Mac, open System Settings > General > Time Machine. Click “Add Backup Disk.” The Pi share should appear. Select it, enter the tmuser credentials, and click “Set Up Disk.” Time Machine will create a sparsebundle on the share and begin the initial backup.

The initial backup transfers the entire Mac and can take several hours over Ethernet and much longer over Wi-Fi. Allow it to run to completion before testing anything. Interrupting the initial backup does not corrupt anything. Time Machine resumes from where it stopped.

After the initial backup completes, verify it from the Mac:

# On the Mac terminal:
tmutil latestbackup
tmutil listbackups

Expected result: tmutil latestbackup returns the path to the most recent backup. Time Machine preferences show the last backup time and the Pi share as the backup destination.

Multiple Macs

Each Mac must have its own Samba share or write to a separate subdirectory. Two Macs pointing at the same path will both try to write sparsebundles and will eventually corrupt each other’s backups.

Add a second user and share section for each additional Mac. In smb.conf:

# Second Mac share -- repeat pattern for additional Macs
[TimeMachine-Mac2]
   path = /mnt/timemachine/mac2
   valid users = tmuser2
   read only = no
   browseable = yes
   create mask = 0600
   directory mask = 0700
   fruit:time machine = yes
   fruit:time machine max size = 300G

Update the Avahi service file to advertise the additional share by adding another txt-record line:

<txt-record>dk1=adVN=TimeMachine-Mac2,adVF=0x82</txt-record>

Security

Firewall

sudo apt install ufw -y
sudo ufw allow OpenSSH
sudo ufw allow from 192.168.1.0/24 to any port 445 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 5353 proto udp
sudo ufw enable

Adjust the subnet to match your network. Port 445 is SMB. Port 5353 is mDNS (Avahi). Restricting both to your local subnet prevents access from other network segments.

SSH hardening

# Copy your public key to the Pi
ssh-copy-id pi@timepi.local

# Disable password authentication
sudo nano /etc/ssh/sshd_config
# Set: PasswordAuthentication no
sudo systemctl restart sshd

Enable FileVault on the Mac

Time Machine encrypts backups when FileVault is enabled on the Mac. This means the sparsebundle on the Pi contains only encrypted data. Even with physical access to the drive, the backup contents are unreadable without the Mac’s encryption key. Enable FileVault in System Settings > Privacy & Security > FileVault before starting Time Machine.

Maintenance

Monitor drive space

df -h /mnt/timemachine
# Check sparsebundle size
du -sh /mnt/timemachine/backups/*.sparsebundle

Time Machine prunes old backups automatically when the drive fills up, but only from within macOS. If the drive reaches capacity, Time Machine may stop backing up rather than pruning. Set fruit:time machine max size in smb.conf to cap sparsebundle growth and leave headroom on the drive for the OS and logs.

Verify backups from macOS

# On the Mac terminal:
# Verify the latest backup
tmutil verifychecksums /

# List all available backups
tmutil listbackups

# Test restore of a specific file
tmutil restore /path/in/backup /tmp/restore-test/

Keep Samba updated

sudo apt update && sudo apt upgrade samba -y
testparm
sudo systemctl restart smbd

Run testparm after every Samba update to confirm the configuration is still valid. macOS updates occasionally tighten SMB compatibility requirements. Check the Samba changelog after major macOS releases.

Back up the Pi configuration

Store a copy of /etc/samba/smb.conf, /etc/fstab, and the Avahi service file somewhere off-Pi. If the Pi fails, these three files plus the drive are all you need to rebuild the NAS. See BorgBackup Raspberry Pi Prune Policies for automating Pi config backups.

Troubleshooting

Share not appearing in Time Machine preferences

# Check Avahi is running
sudo systemctl status avahi-daemon

# Verify mDNS is broadcasting the service
avahi-browse -t _adisk._tcp

# Connect manually if discovery fails
# In Finder: Go > Connect to Server > smb://timepi.local
# Then add the connected share in Time Machine preferences

macOS rejects the share as a Time Machine destination

Confirm vfs objects = catia fruit streams_xattr is in the [global] section and fruit:time machine = yes is in the share section. These must both be present. Run testparm to confirm Samba loaded the configuration without errors. Restart Samba and try again from macOS.

Backup stops with “disk not available” error

# Check the drive is still mounted
df -h /mnt/timemachine

# Check Samba service status
sudo systemctl status smbd

# Check Samba logs for errors
sudo tail -50 /var/log/samba/log.smbd

This error usually means the Pi rebooted and the drive did not remount, or the Samba service stopped. Verify the /etc/fstab entry uses the UUID (not the device path like /dev/sda1), and confirm smbd is enabled to start at boot.

Permission denied during backup

# Check directory ownership
ls -la /mnt/timemachine/backups

# Fix ownership if needed
sudo chown tmuser:tmuser /mnt/timemachine/backups
sudo chmod 770 /mnt/timemachine/backups

Time Machine password prompt on every connection

Open Keychain Access on the Mac, search for the Pi’s hostname or IP, and delete the existing entry. Reconnect to the share and check “Remember this password in my keychain.” If the issue persists, the Mac may have an expired or conflicting Keychain entry from a previous connection.

Sparsebundle appears corrupt

# On the Mac terminal -- verify the sparsebundle
hdiutil verify /Volumes/TimeMachine/ComputerName.sparsebundle

# If verification fails, attempt repair
# Mount the sparsebundle first, then run fsck
hdiutil attach -nomount /Volumes/TimeMachine/ComputerName.sparsebundle
# Note the /dev/diskN returned, then:
sudo fsck_apfs -y /dev/diskN

Sparsebundle corruption most commonly results from power loss on the Pi during an active backup, or from a drive that was disconnected without unmounting. Use the official Pi power supply and a powered USB enclosure to minimise this risk.

FAQ

Can I use a Raspberry Pi 3 for Time Machine backups?

Yes, but the shared USB bus limits throughput to around 25 to 40 MB/s in practice. Initial backups of large Macs will take many hours. For ongoing incremental backups the performance is acceptable. Pi 4 with USB 3.0 is significantly faster and more reliable for regular use.

Why does my Mac not see the Pi in Time Machine preferences?

The most common causes are: Avahi not running or not advertising the _adisk._tcp service type, the Pi and Mac on different network subnets, or the fruit module not loaded in Samba. Run avahi-browse -t _adisk._tcp on the Pi to confirm the service is broadcasting, then check testparm for Samba configuration errors.

What happens if the Pi loses power during a backup?

Time Machine may mark the sparsebundle as in use and refuse to mount it on the next connection. On the Mac, Time Machine usually detects this and repairs the sparsebundle automatically on the next backup attempt. If automatic repair fails, use hdiutil verify and fsck_apfs as shown in the troubleshooting section. A UPS for the Pi and drive eliminates this risk entirely.

Can multiple Macs use the same Pi NAS?

Yes. Give each Mac its own Samba share section and its own Samba user. Each Mac creates its own sparsebundle in its own share directory. Never point two Macs at the same share path.

How do I restore from this backup if my Mac dies?

Boot the new or repaired Mac into macOS Recovery (hold Command+R during startup on Intel, or hold the power button on Apple Silicon). During the setup process, choose “Restore from Time Machine Backup,” connect to the network, and select the Pi share. Enter the tmuser credentials to access the sparsebundle. The restore proceeds identically to restoring from a local Time Machine drive, though at network speeds.

References

About the Author

Chuck Wilson has been programming and building with computers since the Tandy 1000 era. His professional background includes CAD drafting, manufacturing line programming, and custom computer design. He runs PidiyLab in retirement, documenting Raspberry Pi and homelab projects that he actually deploys and maintains on real hardware. Every article on this site reflects hands-on testing on specific hardware and OS versions, not theoretical walkthroughs.

Last tested hardware: Raspberry Pi 4 Model B (4GB), Samsung T7 USB SSD. Last tested OS: Raspberry Pi OS Bookworm Lite 64-bit. Samba 4.17, macOS Sequoia 15.3.