A regular file system like APFS or HFS+ gives access to local storage by providing a low-level API normally accessed by apps through higher-level functions in the operating system. Most file systems don’t extend to storage connected over a network, or to cloud storage, so there need to be network file systems like AFP and SMB that operate over TCP/IP network connections. In macOS, cloud storage is given a separate high-level FileProvider API instead.
Among the dozens of network file systems, those you are most likely to come across on Macs are Network File System (NFS), WebDAV, and the primitive File Transfer Protocol (FTP), in addition to AFP and SMB. The remainder of this article concentrates on the last two as they’re the most commonly used with Macs, although NFS still has its uses, and WebDAV is used for special purposes including calendar access using CalDAV.
In the OSI model of network layers, network file systems mostly operate in layer 7 at the top, the same as other common network protocols including HTTP. They thus depend on a great deal of infrastructure, including TCP/IP.
At their most basic, network file systems provide operations to connect to and disconnect from a share, to negotiate details of that connection, to open, read, write and close remote files, and to obtain a listing of a directory. Those can then be used by higher-level functions when accessing a server over the network, instead of calls to the API for a local file system. The sharing service on the server operates its side of the protocol, working through equivalent calls to the API of its local file system.
Modern local file systems have many more sophisticated features, though. If a network file system doesn’t support extended attributes, for example, it would effectively strip all such metadata from APFS files. Popular network file systems commonly lack provision for APFS sparse and clone files, which leads to transfer and storage inefficiency, as explained later.
AFP (1988)
Apple Filing Protocol, AFP, originated in Classic Mac OS days as part of the Apple File Service suite, and until OS X 10.8 Mountain Lion was the primary network file protocol for Macs. Recent versions rely on TCP/IP over port 548 to establish communication. Although it supports file naming, permissions, extended attributes and advanced locking much as HFS+ does locally, it remains incompatible with sharing of APFS volumes.
AFP became popular in NAS systems when an open source AFP server named Netatalk became available, and could be ported to NAS operating systems including Linux. Support has also been integrated into many network products such as Novell NetWare and Microsoft Windows Server (up to 2008), and of course Apple’s own Time Capsules.
SMB (2013)
Server Message Block, SMB, originated in IBM, for network sharing using IBM PC DOS, and was then adopted by Microsoft. For a while in the mid-1990s it was rebranded as Common Internet File System, CIFS, and it has been implemented independently in Samba, which was used by Apple to provide SMB support in Macs until Mac OS X 10.7 Lion in 2012. Apple then switched to its own implementation SMBX, which became its primary network file system in place of AFP, in OS X 10.9 Mavericks in 2013.
Early versions of SMB were a poor fit for macOS. To overcome the limitations of SMB servers it was often necessary to flatten extended attributes with file data into AppleDouble format, but later versions support what in Windows terms are alternate data streams (ADS), or named streams, which could require configuring an SMB server.
From the outset, SMB has also supported network access to printers, and SMB3 still contains that. Although this is available for connections to Windows printers from macOS, through Printers & Scanners settings, it seems considerably less reliable than using AirPrint, when it’s available.
Apple’s implementation of SMB has endured many bugs and problems over the years, but is now widely used and generally more stable and a lot less inefficient than in the past. However, it doesn’t support APFS special file types. If you copy a sparse file of 1 GB nominal size, occupying a few MB of disk space, then SMB will transfer the whole 1 GB to the share, where the file won’t be in sparse format, and will require 1 GB of shared storage. When that is copied back to local APFS, it remains 1 GB and isn’t reconstituted as an APFS sparse file.
Such are the joys of file sharing.
