iSCSI vs SMB for a Homelab NAS: Which One to Pick

For iSCSI vs SMB on a homelab NAS, pick SMB by default: every Windows PC and Mac speaks it natively, several machines can use one share at once, and the NAS can hand back a single deleted file from a snapshot. Use iSCSI only when one machine needs storage that behaves exactly like its own local disk.

That split covers most homes running an N100 mini-PC next to a Synology or TrueNAS box: SMB for photos, Time Machine and media, plus one small iSCSI LUN for a Windows game library or a Docker host’s app data that must sit on the NAS’s redundant pool. If NFS is also on the table, the three-way version is in iSCSI vs NFS vs SMB.

What is the real difference between iSCSI and SMB?

SMB shares files and iSCSI shares a disk. With SMB, the NAS owns the filesystem, enforces permissions and arbitrates when two clients touch the same file. With iSCSI, the NAS exports a raw block device, the client formats it with NTFS, ext4 or APFS, and the NAS never sees a single file inside it.

RFC 7143 describes iSCSI as “a transport protocol for SCSI that works on top of TCP.” Microsoft’s SMB overview describes SMB as letting an application “read, create, and update files on the remote server.” Everything below follows from that.

The consequence people learn the expensive way: the NAS side of an iSCSI LUN has no lock manager. Two PCs that both mount the same NTFS LUN will each cache metadata, each write, and wreck the volume. It is one LUN per machine unless a cluster filesystem sits on top, as the iSCSI LUN fundamentals guide explains. SMB has no such rule, because arbitrating shared access is the file server’s whole job.

How were iSCSI and SMB compared here?

This comparison relies on published tests and vendor documentation; nothing here was benchmarked in-house. The two write-ups below point the same way as most forum threads: iSCSI wins on small files and metadata-heavy work, SMB matches or beats it on large sequential copies, and configuration swings results more than the protocol does.

The controlled one is Tim Higgins’ SmallNetBuilder test of a QNAP TS-469L, pitting an iSCSI LUN on RAID 5 against a standard share, old enough that the client ran Windows 7. Large file copies favoured SMB: 129.85 versus 116.76 MB/s to the NAS, and 92.56 versus 73.21 MB/s back. Directory copies of many small files flipped hard: 16.32 MB/s over SMB against 277.12 MB/s over iSCSI writing to the NAS, and 19.45 against 39.30 reading back. Higgins suspected write caching, since the content-creation test, where iSCSI scored 17.20 to SMB’s 9.44, “is 95% writes.”

Take that caveat seriously. Over iSCSI, Windows caches writes to what it believes is a local NTFS disk, and depending on target settings the NAS may acknowledge a write before it reaches stable storage. A fast chart can be a safe write racing an unsafe one; the ZFS sync-write version of that trap is covered in NFS vs iSCSI.

The counter-example is recent. In a February 2026 write-up, Tommaso Bombaglio moved a Veeam backup repository on a Synology from iSCSI disks formatted ReFS to an SMB share on Btrfs, over 10GbE. iSCSI had been “consistently capped at a poor 90 MB/s”; SMB ran at around 300 MB/s. He never pinned down a root cause, which is the honest lesson: a badly tuned iSCSI path loses to a boring SMB share.

iSCSI vs SMB side by side

Where SMB wins

Anything more than one device touches. Laptops, phones, the TV and the Proxmox host can all use the same share. Proxmox’s CIFS storage holds disk images, ISOs, templates and backups and is always flagged as shared, though “CIFS does not support snapshots on a storage level,” so VM snapshots fall back to qcow2.

Restores nobody has to file a ticket for. TrueNAS “automatically enables shadow copies for SMB shares, exporting ZFS snapshots as Shadow Copies,” so anyone in the house can right-click a folder and pull last week’s version. Synology’s Snapshot Replication spec offers file browsing and Windows Previous Versions for shared folders; for LUNs, the recovery options are rolling the whole thing back or cloning the snapshot.

Macs. Apple says Time Machine “can back up to a third-party NAS device that supports Time Machine over the SMB network protocol,” and AFP is unsupported from macOS 27. macOS ships no iSCSI initiator at all; QNAP’s FAQ points Mac users at third-party software.

Encryption. SMB 3 encryption can be turned on per share or for the whole server, according to Microsoft’s SMB feature reference. iSCSI authenticates with CHAP, but nothing in the protocol encrypts the payload, so it belongs on a trusted segment.

The Windows 11 24H2 gotcha. Per Microsoft’s signing documentation, 24H2 Enterprise, Pro and Education require SMB signing in both directions, and “Requiring SMB signing also disables guest access to shares.” A passwordless guest share from years ago stops working after the upgrade. Microsoft does not recommend disabling signing as the fix; create a named user on the NAS instead.

Where iSCSI wins

Small files and metadata. The directory-copy gap above is real in direction even if caching inflates it. The client’s own filesystem caches metadata locally instead of asking the server about every file.

Software that wants a local disk. A LUN shows up in Disk Management like a SATA drive. Game launchers, backup agents and anything that refuses UNC paths or loses a mapped drive at login treat it like any other disk. QNAP notes the Microsoft initiator has been built into Windows since Vista. The NAS side is covered in how to set up an iSCSI target on TrueNAS.

SQLite app data on a Docker host. Plenty of self-hosted apps keep their state in SQLite. SQLite’s guidance on network use says its write locks “have been known to operate incorrectly for some network filesystems,” which “has led to database corruption.” The common workaround, mounting CIFS with nobrl, makes things worse; the mount.cifs man page defines that option as “Do not send byte range lock requests to the server.” An ext4-formatted LUN is local storage as far as the kernel is concerned, so locking behaves.

Multipath, if you own the ports. MPIO spreads I/O and fails over across independent NICs. SMB has Multichannel too, and Samba 4.15 made it default-on for Linux and FreeBSD, though NAS vendors may still gate it behind their own settings. A single-NIC N100 box has one path either way.

Storage and backups: the month-nine problem

The NAS cannot see inside a LUN: no Previous Versions, no browsing last Tuesday’s snapshot from the NAS UI. The restore drill has more steps: clone the LUN snapshot, present the clone as a new LUN, attach it to a machine other than the one using the original, mount it read-only, and copy the file out. Run that drill once on a quiet Sunday, before you need it. For SMB, the drill is opening Previous Versions on a folder.

Either way, a snapshot on the same pool is not a backup; replicate snapshots to a second box or push them offsite. Thin LUNs also only hand space back when the client sends UNMAP. If a LUN goes read-only after a NAS reboot, iSCSI troubleshooting walks through the timers involved.

Which one should you pick?

Use SMB for everything people browse, back up or share, and keep iSCSI for the one or two volumes a single machine owns. On an N100 mini-PC plus a NAS, that means SMB for media, documents and Time Machine, local NVMe for container app data, and a LUN only when that app data must live on the NAS’s redundant pool.

Building a LUN per laptop to win a benchmark is yak-shaving with extra restore steps. Neither protocol belongs on the open internet: SMB over Tailscale is fine for fetching a document from a laptop, but iSCSI over any VPN or WAN link turns every latency spike into a SCSI timeout, so keep LUNs on the LAN.

Here is the split as a compose file, using the CIFS named-volume pattern from Docker’s volume documentation. Put SMB_PASSWORD in a .env file next to it rather than in the YAML.

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    user: "1000:1000"
    volumes:
      - /srv/appdata/jellyfin:/config   # local NVMe or an iSCSI LUN, never SMB
      - media:/media:ro                 # library on the NAS over SMB
    ports:
      - "8096:8096"
    restart: unless-stopped

volumes:
  media:
    driver: local
    driver_opts:
      type: cifs
      device: "//192.168.1.20/media"
      o: "addr=192.168.1.20,username=jellyfin,password=${SMB_PASSWORD},vers=3.1.1,uid=1000,gid=1000"

FAQ

is iscsi faster than smb

Usually only for small files and metadata-heavy work. In SmallNetBuilder’s QNAP test, iSCSI copied a folder of small files to the NAS at 277.12 MB/s against 16.32 MB/s over SMB, while SMB led on large file copies. Write caching inflates many iSCSI results, and a poorly tuned iSCSI path can trail SMB badly.

can i use iscsi on a mac

Not without extra software, because macOS ships no iSCSI initiator. QNAP’s documentation points Mac users to third-party initiators such as globalSAN. Most homelabs are better served by an SMB share, which macOS mounts natively and which Apple supports as a Time Machine destination on NAS devices that offer Time Machine over SMB.

why can’t windows 11 24h2 connect to my nas share

Usually because Windows 11 24H2 Pro, Enterprise and Education require SMB signing, and requiring signing blocks guest access. Shares built for passwordless guest login then fail with errors such as 0x80070035. Microsoft advises against disabling signing; create a named user on the NAS, grant it the share, and make sure signing is allowed there.

can docker app data live on an smb share

Media and bulk files can, through a CIFS named volume as Docker’s documentation shows. Anything holding a SQLite database should not: SQLite’s maintainers warn that network filesystem locking has caused corruption, and the nobrl mount option stops lock requests reaching the server at all. Keep app data on local NVMe or an iSCSI LUN that one host owns.

Related across the network

• How to Implement SAN Storage: Design, Paths and Tests — sanstorageguide.com
• What Is a SAN Storage Area Network? Block Storage Explained — sanstorageguide.com