Folding a NAS Into Your Daily Workflow: Linux, macOS, and Windows

A NAS is only as good as how invisibly it folds into the way you already work. The box itself is the easy part — you pick TrueNAS SCALE or OpenMediaVault, drop in some drives, and you have a blinking appliance on the network. The hard part, the part that decides whether the thing becomes load-bearing infrastructure or an expensive parking lot for files you forget about, is the integration: which protocol you mount on each operating system, whether those mounts survive a reboot and a laptop lid-close, how you separate “live storage I work off of” from “backup target I trust my life to,” and — the part almost everyone underestimates — how the network in between quietly decides which activities feel instant and which feel like wading through mud. Get those four things right and the NAS disappears into your workflow the way a good tool should. Get them wrong and you will fight it daily.

This guide assumes you have a working TrueNAS SCALE (current stable is 25.10 “Goldeye”) or OpenMediaVault box. If you are still choosing hardware and an OS, the TrueNAS SCALE deep dive and the YXK Zero1 NAS guide cover that ground, and the drive selection and health post covers the drives. One housekeeping note on OMV: version 7 “Sandworm” reached end-of-life in June 2026 alongside Debian 12, so new OMV installs should be on version 8. Everything below applies to both major NAS OSes — they expose the same handful of network protocols, and the client side is identical regardless of what serves the share.

The two jobs a NAS does, and why they want different things

Before touching a config file, separate the two fundamentally different jobs you are asking the NAS to do, because they have opposite requirements and conflating them is the root of most NAS frustration.

Live storage is the share you actively work off of — the media library Jellyfin reads, the photo catalog Lightroom browses, the project directory you open files from all day. Here you want low latency, transparent mounting, and native-feeling file semantics. The data is “hot,” you touch it constantly, and the protocol’s interactive responsiveness matters more than raw throughput.

A backup target is a destination you write to and almost never read from — until the day everything is on fire and you read from it desperately. Here you want throughput, integrity, and isolation. The defining property of a good backup target is that a mistake on your laptop (a wayward rm -rf, ransomware, a sync client that decides to delete the cloud copy) cannot propagate to it. That requirement — isolation from your live environment — is in direct tension with the convenience of a permanently-mounted live share.

The single most common NAS mistake is treating a mounted SMB share as a backup. A drive letter mapped to \\nas\backup that is writable from your desktop is not a backup; it is a second copy of your data sitting one cryptolocker away from your first copy. Real backups go through a tool that versions and ideally cannot be silently overwritten. We will come back to this; hold the thought.

Picking the protocol: SMB, NFS, or iSCSI

Both TrueNAS and OMV can serve the same dataset over multiple protocols simultaneously. The three that matter:

The decision rule is simpler than the table suggests. If a Windows or macOS machine touches the share, use SMB. SMB3 is the lingua franca; it handles authentication, ACLs, and cross-client locking properly, and it is what Apple and Microsoft actually test against. If it is Linux-to-Linux on a trusted LAN, NFS is lighter and faster for the same workload, with less per-operation overhead and cleaner UID-based permissions — see the NFS and network storage deep dive for the full version. Reach for iSCSI only when a single machine needs what looks like a local block device — a database that wants raw disk, or a single-writer VM datastore — because iSCSI exports a block volume, not a filesystem, and two machines mounting the same iSCSI LUN read-write will corrupt it spectacularly.

A practical mixed-household pattern: serve the media and documents datasets over both SMB and NFS. Linux boxes mount NFS, Macs and Windows machines mount SMB, and ZFS underneath keeps everyone consistent. The only rule is do not have an NFS client and an SMB client writing to the same files at the same time and expecting cross-protocol locking to save you — it will not.

Linux: mounts that survive reboots and sleep

On Linux you have a real choice between NFS and SMB (here called CIFS). For a Linux-only path to a Linux-served NAS, NFSv4 wins on overhead. The naive approach is a static /etc/fstab line, but a hard static mount to a network host will hang boot if the NAS is unreachable and stall a laptop that suspends away from the network. The right pattern is systemd automount, which mounts the share lazily on first access and unmounts it when idle, so a missing NAS never blocks anything.

NFSv4 with automount in /etc/fstab:

nas.lan:/mnt/tank/media  /mnt/media  nfs4  \
  rw,_netdev,noatime,soft,timeo=150,retrans=3,\
  x-systemd.automount,x-systemd.idle-timeout=600  0  0

The x-systemd.automount flag is the magic: the path /mnt/media exists immediately at boot but the actual NFS mount only happens when something reads it, and idle-timeout=600 unmounts after ten idle minutes. soft plus timeo/retrans means an unreachable NAS returns an I/O error after a bounded wait instead of hanging a process forever in uninterruptible sleep — the correct trade-off for a workstation (use hard only for VM datastores where you would rather block than risk silent data loss).

For SMB from Linux, the equivalent with a credentials file that keeps your password out of fstab:

//nas.lan/media  /mnt/media  cifs  \
  credentials=/etc/cifs-nas.cred,uid=1000,gid=1000,\
  iocharset=utf8,vers=3.1.1,_netdev,\
  x-systemd.automount,x-systemd.idle-timeout=600  0  0

With /etc/cifs-nas.cred containing username=jeff and password=... and locked down with chmod 600. Pin vers=3.1.1 explicitly; letting the kernel negotiate occasionally lands on an older, slower dialect.

For backup, Linux is the easy case: restic or borg to the NAS over SSH/SFTP, or rsync to an NFS-mounted backup dataset. The restic pattern, pointed at an SFTP endpoint so there is no permanently-writable mount sitting around:

1
2
3
4

export RESTIC_REPOSITORY="sftp:jeff@nas.lan:/mnt/tank/backups/restic-$(hostname)"
restic init                       # once
restic backup ~/Documents ~/code  # nightly via systemd timer
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

For the broader strategy these tools fit into, the backup strategy post lays out the policy; here the point is only that the Linux client side is clean and scriptable.

macOS: SMB, the .DS_Store tax, and Time Machine

macOS speaks SMB3 natively and that is what you should use — Apple deprecated AFP years ago. The interactive path is Finder’s Go → Connect to Server (Cmd-K) with smb://nas.lan, which is fine for occasional access but does not survive a reboot. For a mount that comes back automatically, use autofs via /etc/auto_smb referenced from /etc/auto_master, or simply add the share to Login Items so it remounts at sign-in.

Two macOS-specific frictions are worth knowing before they bite you.

First, the .DS_Store tax. Finder writes a hidden .DS_Store metadata file into every directory it browses, and over SMB this means a storm of small writes and a litter of these files across your NAS — annoying for Linux/Windows users sharing the same dataset. Disable it for network volumes once:

1

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

Second, and newer: macOS Tahoe (macOS 26) tightened SMB signing defaults, which broke connections and Time Machine backups against NAS boxes configured with relaxed signing — the infamous BACKUP_FAILED_DISCONNECTED_DISK_IMAGE error against TrueNAS, Synology, and QNAP. The durable fix lives in /etc/nsmb.conf on the Mac:

1
2
3
4
5

[default]
signing_required=yes
streams=yes
soft=yes
mc_prefer_wired=yes

signing_required=yes aligns the client with Tahoe’s stricter posture (and with how you should have your NAS configured anyway), streams=yes keeps macOS extended attributes working, and mc_prefer_wired=yes tells SMB multichannel to favor your Ethernet over Wi-Fi when both are up. Counterintuitively, on older macOS against an SMB2-only target, the performance advice was the opposite — signing_required=no to shed the signing overhead — so match this file to your actual NAS config and macOS version rather than copying a random forum snippet.

Time Machine over SMB is genuinely good once configured. On the NAS side you flag the dataset’s SMB share as a Time Machine target (TrueNAS: set the share Purpose to the Time Machine option, or enable the Time Machine toggle and an optional per-share quota; OMV: the equivalent flag in the SMB share’s advanced settings). The Mac then sees it in System Settings → General → Time Machine → Add Backup Disk. ZFS underneath gives you something a Time Capsule never could: the Time Machine sparsebundle sits on a checksummed, snapshotted dataset, so the backup of your Mac is itself protected against bit rot and can be replicated offsite. Set a quota so one Mac’s backups cannot consume the whole pool.

Windows: drive letters, credentials, and versioned backup

Windows is SMB-only in practice — there is an NFS client in the Enterprise/Pro-for-Workstations editions, but it is clunky and pointless when SMB3 is the native, well-tested path. The two things to get right are persistence and credentials.

The classic net use maps a drive letter, and /persistent:yes makes it survive reboot:

1

net use Z: \\nas.lan\media /user:jeff /persistent:yes

The PowerShell equivalent, which is the modern and scriptable form:

1
2

New-SmbMapping -LocalPath 'Z:' -RemotePath '\\nas.lan\media' `
  -Persistent $true -UserName 'jeff' -Password (Read-Host -AsSecureString)

Store the credential in Windows Credential Manager (cmdkey /add:nas.lan /user:jeff /pass) rather than embedding it in a script. One Windows footgun: mapped drives are per-user and do not exist in elevated (admin) contexts by default, so a tool running as administrator will not see Z: — reference the UNC path \\nas.lan\media directly in that case.

For backup, do not rely on a mapped drive as your backup for the reasons in the two-jobs section — File History pointed at a writable mapped drive is better than nothing but still lives in your blast radius. The stronger pattern on Windows is the same as everywhere else: a versioning backup tool writing to a destination it controls. restic runs natively on Windows and is the cleanest option:

1
2

$env:RESTIC_REPOSITORY = "rest:http://nas.lan:8000/$env:COMPUTERNAME"
restic backup C:\Users\jeff\Documents C:\Users\jeff\Pictures

Running rest-server on the NAS (in append-only mode, --append-only) is the detail that turns a “second copy” into a real backup: even if your Windows box is compromised, an append-only restic server will not let the attacker delete existing snapshots. That is the property a mapped drive can never give you.

How the network decides what feels fast

Here is the part most NAS guides skip and most NAS owners learn the hard way. The speed of any NAS operation is set by the slowest link in a chain, and that chain has more links than you think:

  [ App / RAM ]
       |  memory bandwidth (effectively infinite here)
       v
  [ Client NIC ]  <-- 1 / 2.5 / 10 GbE
       |
       v
  [  Switch  ]    <-- must also be 2.5/10G, non-blocking
       |
       v
  [  NAS NIC ]   <-- 1 / 2.5 / 10 GbE
       |
       v
  [ Protocol: SMB/NFS ]  <-- per-op overhead, signing, single-stream limits
       |
       v
  [  ZFS ARC (RAM cache) ]  <-- hot reads served here at RAM speed
       |  cache miss
       v
  [  Disks: HDD / SSD / NVMe ]  <-- the usual real bottleneck

Two facts fall out of this chain. First, your storage is usually the bottleneck, not your network — until it isn’t. A single spinning HDD sustains roughly 120–200 MB/s on large sequential transfers and collapses to 10–30 MB/s on thousands of small files. Second, the network tier only matters relative to what the disks behind it can actually deliver.

The headline consequence: 10GbE behind a single hard drive is a trap. You will spend money on NICs and a switch and see no improvement on most transfers, because the drive was always the limit. 10GbE pays off only when the storage can keep up — an all-SSD pool, NVMe, or enough HDDs striped together to aggregate past 2.5GbE — or for the one workload where it shines: many clients hitting the NAS at once, where the aggregate exceeds any single link.

Now map that to actual activities, because the right answer is workload-dependent:

The pattern: streaming, backups, and document work are fine on plain 1GbE forever. The things that justify faster networking are video editing off the NAS and saturating-copy workflows — and even then the drives, not the Gbps, are usually what you must fix first. Latency-bound work (photo browsing, compiling, anything with many small files) is barely helped by more bandwidth at all; it wants a faster storage medium and a special metadata vdev, which is a ZFS topology question covered in the ZFS homelab storage post, not a network upgrade.

A few real knobs that help once you have identified the right bottleneck. Jumbo frames (ip link set eth0 mtu 9000, matched end to end including the switch) cut per-packet overhead and add a few percent on large sequential transfers — worthless for small files and a source of mysterious breakage if any device in the path is left at 1500. SMB multichannel lets a single SMB session stripe across multiple NICs; enable it on Samba/TrueNAS with server multi channel support = yes and a client with two interfaces can exceed one link’s speed. And the classic disappointment: link aggregation (LACP) does not speed up a single transfer. A two-port LACP bond gives two clients a full link each, but any one TCP flow rides one physical port — bonding is for aggregate concurrency, not single-stream speed. If your goal is one fast transfer, a single faster NIC beats two bonded slower ones. For the wiring and switch side of all this, the home network design guide goes deeper.

Backup: where the NAS fits in 3-2-1

Return to the thought from the top: a mounted share is not a backup. The discipline that actually protects you is 3-2-1 — three copies of the data, on two different media, with one copy offsite — and a NAS is exactly one leg of that, never the whole thing.

A NAS does two distinct backup jobs well. It is an excellent backup target for your laptops and desktops (restic/borg/Time Machine writing to it), and it is an excellent source to replicate offsite (ZFS snapshots sent somewhere else). What it is not, by itself, is safe: a fire, a theft, a lightning strike, or a fat-fingered zfs destroy takes the whole box and every “backup” sitting on it simultaneously.

The two properties that turn NAS storage into trustworthy backup are versioning (so yesterday’s good file survives today’s corruption) and immutability or isolation (so a compromise of the client cannot reach back and delete the backups). Snapshots provide versioning on the NAS side; append-only restic/borg repos and pull-based backups provide the isolation. A ZFS snapshot is not a backup — it lives on the same pool as the data and dies with it — but it is a superb local undo and the basis for cheap offsite replication.

The offsite leg, using ZFS native replication (TrueNAS exposes this as a Replication Task in the UI; the CLI underneath is just):

1
2
3

zfs snapshot tank/data@2026-06-13
zfs send -i tank/data@2026-06-12 tank/data@2026-06-13 \
  | ssh backup-host zfs recv -F backup/data

Incremental sends move only changed blocks, so after the first seed the nightly offsite sync is small and fast. Point it at a friend’s NAS, a cheap VPS, or a cloud target, ideally reached over a private overlay so you are not exposing services to the internet — the Tailscale homelab networking post covers that pattern.

Per-OS backup tooling, summarized:

If you would rather have a sync-and-share layer on top of all this — phone photo auto-upload, a Google-Drive-like web UI — that is a different tool living beside the file shares, not a replacement for them; the self-hosted Nextcloud guide covers running Nextcloud against the same pool.

A concrete reference setup

Tying it together for a typical mixed household with a ZFS-based NAS and a 2.5GbE network:

• Datasets: tank/media, tank/documents, tank/photos, tank/backups, each a separate ZFS dataset so snapshots and quotas are independent.
• Sharing: media, documents, photos over both SMB (for the Macs and the Windows desktop) and NFS (for the Linux boxes). backups over SMB for Time Machine plus an SFTP/rest-server endpoint for restic — never as a general writable mount.
• Linux laptop: NFSv4 x-systemd.automount mounts for the three live datasets; nightly restic-over-SFTP to tank/backups/restic-thinkpad via a systemd timer.
• Mac: SMB login-item mounts with .DS_Store suppression and /etc/nsmb.conf set for Tahoe-correct signing; Time Machine targeting the flagged backups share with a 1 TB quota.
• Windows desktop: persistent New-SmbMapping drives for media and documents; restic to the append-only rest-server for the user profile.
• The NAS: hourly snapshots on documents and photos (kept 24h), daily kept 14d; a nightly ZFS replication task pushing incrementals to an offsite box over Tailscale.
• Network reality check: 2.5GbE is plenty for streaming, backups, and document work off the HDD pool. The one machine that edits 4K video gets a direct 10GbE link to an NVMe special-vdev-backed dataset; everyone else stays on 2.5GbE because, for what they do, the drives — not the network — were always the limit.

For encrypting any of the datasets that hold sensitive material, the LUKS full-disk encryption post covers the disk-level approach and ZFS native encryption is the in-pool alternative. And if a media server is part of the plan, the Jellyfin vs Plex vs Emby comparison covers serving that media dataset to your TVs.

Verdict

A NAS becomes invisible infrastructure when you make four decisions deliberately instead of by default. Pick the protocol per platform: SMB anywhere Windows or a Mac is involved, NFS for Linux-to-Linux on a trusted LAN, iSCSI only when one machine needs a pretend-local disk. Make mounts non-blocking: systemd automount on Linux, login-item or autofs mounts on macOS with the Tahoe signing fix, persistent SMB mappings on Windows — so a sleeping laptop or an offline NAS never hangs your machine. Keep live storage and backup separate: a writable mounted share is a second copy, not a backup; real backups go through a versioning tool (restic, borg, Time Machine) writing to a destination it controls, ideally append-only, with the NAS replicating one copy offsite to satisfy 3-2-1.

And size the network to the actual bottleneck, which is almost always the disks. Streaming, backups, and document work are fine on 1GbE indefinitely. 2.5GbE is the sweet spot that costs little and outruns a single HDD. 10GbE is worth it only for editing large media off the NAS or for many concurrent clients, and only once the storage behind it — SSD, NVMe, or a wide striped pool — can actually fill the pipe. Spend on drives before you spend on networking, because the fastest switch in the world cannot make a lone spinning disk go faster than the physics of one spinning disk.

Sources

• TrueNAS SCALE 25.10 (Goldeye) Version Notes
• TrueNAS Documentation: SMB Shares
• openmediavault 7 (Sandworm) Release and EOL notes
• openmediavault Documentation: Releases
• Samba Wiki: SMB3 Multichannel
• How to Set Up Samba Multi-Channel for High Performance on Ubuntu
• Fix for macOS 26 Tahoe Time Machine SMB backup failures — nsmb.conf guide
• TrueNAS Forums: macOS SMB write performance with 10GbE and multichannel
• XDA: 10GbE is pointless on your NAS unless you’re using it for this one thing
• UGREEN NAS: 5 Common Fixes for Slow NAS Transfers
• NAS Compares: 20 Fixes to Get Great 10GbE Speeds
• Arch Wiki: NFS — systemd automount
• Arch Wiki: Samba — Mount with systemd/automount
• restic documentation: REST server and append-only mode
• OpenZFS: zfs-send / zfs-receive replication