Time Machine backups to a Raspberry Pi NAS using Samba

Introduction

Time Machine Raspberry Pi NAS setups aren’t just some hobbyist pipe dream. They’re functional, cheap, and surprisingly stable when configured right. Time Machine, Apple’s built-in backup tool, supports SMB starting with Big Sur. That means even a $35 Raspberry Pi can act like a local network backup target, no overpriced Apple gear or subscription nonsense involved. A lot of folks think you need fancy hardware or a degree in networking for this. You don’t. What you do need is a Raspberry Pi, Samba running on it, and some external storage mounted and shared the right way.

macOS needs SMB3, case sensitivity off, and the fruit module in Samba to behave. It also prefers using sparsebundles for backups over a network share. The Pi’s got to mount drives consistently on boot, serve SMB shares properly, and not flake out when Time Machine checks in. If any of those steps go sideways, your Mac will throw errors that sound more helpful than they are.

You’ll also need to handle a few permissions quirks and make sure your Pi doesn’t lose power during backup. If it does, you’ll get to practice recovering corrupt sparsebundles. Spoiler alert: it’s not fun. But if the Pi’s got stable power, a decent drive, and Samba set up with the right options, you’ll have a working NAS backup target for your Mac. No recurring fees, no external servers, and no mystery bills three months from now.

Key Takeaways

• Raspberry Pi can act as a fully functional Time Machine NAS with Samba.
• SMB3 support and the fruit module are critical for macOS compatibility.
• Stable power, reliable networking, and proper disk formatting prevent most issues.
• Each Mac should back up to its own share to avoid sparsebundle corruption.
• Ethernet beats Wi-Fi for consistency and speed—especially on large backups.

Hardware Requirements

Supported Raspberry Pi models

Time Machine backups over SMB work best with Raspberry Pi 4 and 5. You can technically use a Pi 3B+, but it’s like towing a trailer with a lawnmower. The 4GB and 8GB variants of the Pi 4 give you enough headroom to handle file sharing, logging, and simultaneous network traffic without constant swapping.

External drives and power considerations

You’ll want a USB 3.0 drive, preferably SSD. Mechanical hard drives work, but they’re slower and more likely to whine during large file transfers. Plug them into the blue USB ports on the Pi 4 or Pi 5. If your drive doesn’t have its own power supply, use a powered USB hub. Otherwise, your Pi may reboot mid-backup like it just gave up.

Network gear that doesn’t suck

Use Ethernet. Wi-Fi works if you enjoy broken backups and waiting around. Gigabit Ethernet is available on the Pi 4 and 5, and it’ll actually saturate if you’ve got a fast enough SSD. Skip consumer-grade routers that crash if you breathe near them. If you’re stuck with Wi-Fi, make sure the Pi’s on 5GHz, not some congested 2.4GHz band used by microwaves and baby monitors.

SD cards that won’t flake out

Don’t trust the cheapest SD card from the clearance bin. Use a 16GB or larger A1-rated card from a decent brand. Better yet, boot from an SSD using USB boot if you’re on a Pi 4 or 5. You want uptime, not unexpected corruption every time there’s a brownout.

Power supplies that can actually supply power

Use the official Raspberry Pi power adapter. Don’t skimp. If your Pi resets randomly under load, your backups will get corrupted and you’ll spend more time fixing sparsebundles than actually backing anything up.

Software Prerequisites

macOS versions that actually play nice

Time Machine didn’t always work with SMB. It used AFP until macOS Big Sur decided AFP was old news. Anything from Big Sur onwards (including Monterey, Ventura, and Sonoma) supports Time Machine over SMB3. That’s the minimum. If you’re still on Catalina or older, you’re out of luck without some serious hacks.

Raspberry Pi OS and Samba version

Stick with Raspberry Pi OS Lite if you don’t need a desktop. It’s less bloated, and you’ll configure everything over SSH anyway. Make sure Samba version 4.8 or newer is installed. That’s where proper fruit module support kicked in, which is necessary for macOS to even recognize the share as a valid Time Machine target.

Required packages

You’ll need:

• samba
• avahi-daemon
• netatalk (optional but helpful if you’ve got older Macs)
• hfsplus and exfat-utils if you’re dealing with older drives
• rsyslog or journald for logging errors before they become mysteries

Install everything with apt, then update your packages so you don’t spend hours debugging bugs that were fixed a year ago.

Drive formatting

Time Machine doesn’t care what the Pi uses internally. macOS backs up to a sparsebundle, so EXT4 is just fine. Don’t bother trying to get APFS or HFS+ support working on Linux—it’s clunky and unnecessary. Format your external drive to EXT4 and let Samba handle the translation.

Avahi and Bonjour support

If your Mac can’t find the share automatically, Avahi is probably missing or misconfigured. That’s your zero-conf name broadcasting tool. It lets your Mac see the Pi as raspberrypi.local or whatever you name it. Without it, you’ll be stuck typing IPs like it’s 1998.

Prepping the Raspberry Pi

Flash Raspberry Pi OS and enable SSH

Download Raspberry Pi Imager and burn Raspberry Pi OS Lite to your SD card or SSD. Before you eject the card, create an empty file called ssh in the boot partition. This tells the Pi to enable SSH on first boot. If you want Wi-Fi, toss in a wpa_supplicant.conf file too. Or just plug in Ethernet like a sane person.

Boot it up and update immediately

First boot? SSH in (ssh pi@raspberrypi.local) and change the default password unless you like surprises. Run:

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

It takes a while, but it’s worth it unless you enjoy chasing down bugs caused by outdated packages. Reboot when done.

Create a new user for backups

Don’t use “pi” for everything. It’s lazy and insecure. Create a dedicated Samba user:

sudo adduser tmuser
sudo smbpasswd -a tmuser

Use a decent password. You’ll need it every time your Mac connects to the share.

Check time and hostname settings

macOS hates time drift. Sync the Pi with NTP using timedatectl and make sure the hostname is something human-readable like timepi. It’ll make network discovery easier later.

Mount your backup drive

Plug in the USB drive. Use lsblk or blkid to get the UUID. Edit /etc/fstab to mount it automatically on boot:

UUID=your-drive-uuid /mnt/timemachine ext4 defaults,noatime 0 2

Create the directory first (sudo mkdir -p /mnt/timemachine) and test with sudo mount -a.

If that mount fails, fix it now or backups will break the moment the Pi reboots.

Performance Optimization

Use SSDs if you value your time

Hard drives work, but they’re slow. A decent SSD over USB 3.0 will dramatically reduce backup times and file indexing delays. The Pi 4 and 5 have USB 3 ports—use them. If your SSD comes with a SATA-to-USB adapter, make sure it doesn’t bottleneck the speed.

Ethernet beats Wi-Fi every time

Gigabit Ethernet on the Pi 4 and 5 can push around 100MB/s with the right setup. Wi-Fi might get you 20–30MB/s on a good day. And let’s be honest, it’s rarely a good day when you’re depending on Wi-Fi for backups.

Monitor backup traffic

Use iftop or nload to see real-time network usage. If things seem slow, it could be the Pi, the router, or your Mac’s throttling. Use htop and iotop on the Pi to check CPU and disk usage:

sudo apt install htop iotop iftop

Disable indexing on the share

macOS loves to index everything, but it’s not necessary on a backup volume. Disable Spotlight indexing for that share:

mdutil -i off /Volumes/timemachine

Reduce overhead on the Pi

Turn off any background services you don’t need. Stop unnecessary daemons, remove GUI packages, and keep logs rotated:

sudo systemctl disable someuselessservice
sudo apt autoremove

Keep Samba’s cache warm

Samba does better with consistent access patterns. Don’t let the Pi sit idle for days, then expect the first backup to be smooth. Trigger a small Time Machine backup regularly to keep things responsive.

Tune your Samba config

Add these to your global section in smb.conf:

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

These help squeeze out extra performance on slower hardware.

Thermals matter

If your Pi gets too warm, it’ll throttle and backups will crawl. Use a heatsink and fan or a case with ventilation. Check temps:

vcgencmd measure_temp

Backup frequency settings

macOS backs up hourly by default. You can change this with tmutil or TimeMachineEditor if you want to reduce I/O load and wear on your SSD.

Avoid simultaneous heavy tasks

Don’t stream video from Plex or rebuild Nextcloud indexes during a backup. The Pi’s not a server farm—it’s a glorified calculator with USB ports. Treat it like one.

Securing the Setup

Use SSH keys and ditch passwords

Enable key-based authentication for SSH access. It’s faster, safer, and makes brute force attempts a waste of time. On your Mac:

ssh-keygen -t rsa
ssh-copy-id pi@raspberrypi.local

Now disable password login in /etc/ssh/sshd_config:

PasswordAuthentication no

Restart the SSH service and enjoy not typing your password 15 times a day.

Limit Samba access

Lock Samba to a specific user and, if you’re paranoid, a specific IP or subnet. In smb.conf, use:

hosts allow = 192.168.1.

Don’t open up your Pi to the entire LAN unless you enjoy mystery connections.

Encrypt where it matters

You don’t need to encrypt the drive on the Pi, but enable FileVault on your Mac. It protects your data before it ever hits the network. That way, even if someone nabs your backup, it’s encrypted at the source.

Use firewall rules

Install ufw on the Pi and allow only needed ports:

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

This keeps random devices or nosy guests from poking at your backup share.

Update like it’s your job

Raspberry Pi OS gets security patches regularly. Run:

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

Set up a cron job or a reminder to do this at least monthly. Don’t skip it—bugs in Samba or Avahi can break your whole setup.

Audit who’s accessing what

Use Samba logs and system logs to track who’s connecting and when. If you see something weird, change your passwords and tighten up access. It’s your data—don’t treat it like a public bathroom.

Scaling Up Your NAS

Add more drives without drama

Plug in additional USB drives and format them with EXT4 just like the first. Label them clearly (backup1, backup2, etc.) and mount each in its own directory:

/mnt/backup1
/mnt/backup2

Use UUIDs in /etc/fstab to make sure they always mount correctly, no matter what order they’re detected in.

Mount multiple shares in Samba

Edit smb.conf and add new sections for each share:

[backup1]
   path = /mnt/backup1
   ...

[backup2]

path = /mnt/backup2 …

Give each Mac its own share to avoid backup collisions.

Set quotas if you don’t trust yourself

Samba doesn’t handle quotas on its own, but the underlying EXT4 file system does. Set up disk quotas to make sure one Mac doesn’t eat the entire drive. Use quota tools and edit /etc/fstab to enable usrquota.

Try OpenMediaVault if you like GUIs

If editing config files makes your eye twitch, install OpenMediaVault. It gives you a web interface to manage users, shares, disks, and more. It’s heavier than a plain OS install, but more user-friendly for non-terminal folks.

Mirror drives for redundancy

No, a USB hub full of drives isn’t RAID, but you can set up software RAID with mdadm if you’re brave. RAID 1 mirrors give you simple redundancy. Be prepared to troubleshoot weird kernel messages when drives drop unexpectedly.

Upgrade to a better Pi or real NAS

If you’re pushing multiple backups, running additional services, or hitting I/O limits, the Pi might not cut it long-term. A used mini PC or entry-level NAS (like Synology or TrueNAS box) offers more ports, RAM, and performance.

Make the Pi’s backups resilient

Back up the Pi’s OS too. Use rsync or take a snapshot of the SD card and store it on your network. That way, if your Pi fails, you’re not starting from scratch.

USB vs SATA tradeoffs

USB 3.0 is solid, but a proper SATA interface (via HAT or adapter board) can offer better reliability and power handling. Don’t expect datacenter speeds, but fewer weird disconnects is a win.

Backup the backups

It sounds dumb until the drive dies. Copy sparsebundles to another external drive or sync them to cloud storage with rclone. Air-gapped backups save you from ransomware, user error, or power spikes.

Plan for the future

Leave headroom in storage. Today it’s 256GB, next year you’re backing up a 2TB Mac with Lightroom libraries and 4K video. Don’t design a NAS you’ll outgrow in six months.

Common Pitfalls

“Disk not available” errors

This usually means your Pi rebooted and didn’t mount the drive properly. Check /etc/fstab, and make sure your drive is powered and has a stable connection. Reboot and verify the mount manually.

Sparsebundle not visible or broken

If your Mac created a sparsebundle and it’s not mounting, it might be corrupt. Run hdiutil verify or fsck_hfs on it. If it fails, you can try repairing it, but sometimes you’ll need to start fresh. That’s why you copy backups before they break.

Permission denied during backups

This happens if the Samba user doesn’t have write access to the share. Double-check that the directory is owned by the user, and that smb.conf allows write access. Also, make sure no other process is locking the sparsebundle.

Time Machine asks for password constantly

If macOS keeps prompting for a password, your credentials may not be saved in the Keychain. Open Keychain Access, delete the old entry, and reconnect to the share, making sure to check “Remember this password.”

Drive isn’t mounting on boot

If the Pi boots without your backup drive mounted, Time Machine won’t find the share and you’ll see cryptic errors. Test your fstab entry with sudo mount -a, and use UUIDs instead of device names.

Avahi not working

Your Mac can’t find the Pi at raspberrypi.local? Avahi is probably missing or crashed. Reinstall it and restart the service:

sudo apt install avahi-daemon
sudo systemctl restart avahi-daemon

Samba logs flooded with errors

Run tail -f /var/log/samba/log.smbd and look for repeated warnings. Common ones include bad user mappings, denied access attempts, and share not found. Fixing typos in smb.conf solves a lot.

Backup seems stuck

If the initial backup hangs forever, it’s often a performance issue or a bad network connection. Use Activity Monitor on macOS to see if backupd is working. Use iotop on the Pi to monitor disk I/O.

Your Pi runs out of space

Sparsebundles grow over time. If your Pi’s drive fills up, backups will stop silently. Use df -h and clean up old versions or move to a larger drive.

Updates break everything

Samba updates can sometimes change default behaviors. After a big update, recheck smb.conf and your user permissions. Don’t assume your previous settings are still valid.

Summary and Maintenance Tips

Check backups actually happen

Just because Time Machine says it’s backing up doesn’t mean it’s telling the truth. Open Time Machine preferences regularly and check the last backup time. If it’s been a week, something’s wrong.

Reboot the Pi occasionally

Uptime is great, but Linux benefits from a reboot once in a while. Kernel updates, memory leaks, and weird behavior usually clear up with a restart. Schedule one monthly or after major updates.

Update everything, not just the Mac

Keep your Raspberry Pi packages and Samba version up to date. That includes Avahi, the kernel, and any logging tools. An outdated Pi means you’re one macOS update away from incompatibility.

Archive old backups

Sparsebundles can be copied while unmounted. Archive them to another drive before major macOS upgrades, system wipes, or if you’re switching machines. Don’t assume Time Machine will “just work” across devices.

Use logging to catch early failures

Check Samba logs, system logs, and disk usage weekly. Set up email or push alerts with logwatch or custom scripts if something goes off the rails. Early warning beats data loss.

Document your setup

Keep a text file or markdown doc with your exact mount paths, smb.conf tweaks, user names, and passwords (stored securely). It’ll save you hours if you ever have to rebuild after a crash.

Don’t rely on one backup

A Raspberry Pi NAS is solid, but not infallible. Supplement it with a Time Machine drive, iCloud, or something else. One backup is none. Two backups are a decent start.

Rotate drives if you’re cautious

If you’re really serious, use two external drives and alternate them weekly or monthly. Store one off-site if you’re worried about theft, fire, or hardware failure.

Respect your Pi’s limits

It’s great for backups, but don’t overload it. Keep it cool, powered, and updated. Treat it like the reliable little box it is—not a full-blown server rack.

Test restores now, not later

Try restoring a file or folder every so often. If Time Machine won’t let you, you’ve got a problem. Better to find out now than after a disk crash.

FAQ

Can I use a Raspberry Pi 3 for Time Machine backups?
You can, but it’s slower and more prone to issues under load. Stick with a Pi 4 or 5 if you want reliability and speed.

Why does my Mac not see the Pi?
Check that Avahi is running and your Pi’s hostname resolves with .local. If you still don’t see it, try connecting directly via IP.

Is this setup safe for sensitive data?
It’s as safe as you make it. Use strong passwords, enable encryption on your Mac, and limit Samba access to trusted devices.

What happens if the power goes out during a backup?
You risk sparsebundle corruption. Use a UPS for your Pi and drive if backups are critical.

Do I need to reformat the drive for EXT4?
Yes, for best performance and compatibility. macOS writes to a sparsebundle, so it doesn’t care what the underlying file system is.

Can multiple Macs use the same Pi NAS?
Yes, but each Mac should have its own share or subdirectory. Don’t point two Macs at the same sparsebundle.

Will Time Machine work over Wi-Fi?
It works, but it’s slower and more error-prone. Use Ethernet whenever possible.

How much storage should I allocate?
Time Machine likes at least 2–3x the size of your Mac’s used space. For multiple Macs, plan accordingly.

Is OpenMediaVault necessary?
No. It’s optional. Useful if you prefer a web UI over SSH and command-line edits.

How do I restore from this backup if my Mac dies?
Boot into macOS Recovery, connect to the network, and select your Pi share during the restore process. It’s slower than local drives but works fine.

References

• Apple Time Machine Overview
• Raspberry Pi OS Documentation
• Samba Configuration Guide
• macOS Time Machine over SMB Notes
• Avahi and Bonjour Setup