Primers › Networking

Network file shares

Two colleagues on the same team need the same files: one saves a spreadsheet, and the other opens it a minute later from a different computer. The usual answer is a network file share, a shared folder on a storage box on the office network that both of their computers can open. Nobody emails attachments back and forth, and each computer’s access to the folder is a network connection with a port and a direction.

The example below follows one setup through the whole primer:

• pc01, one colleague’s Windows PC, opens the team folder as \\nas01.example.com\team.
• pc02, the other colleague’s Linux PC, opens the same folder.
• nas01.example.com, a storage box on the office network, holds the shared folder.

A few terms

• Share: a folder that one machine makes available to others over the network.
• Mount: attach a share so it appears as part of the local file system, as a drive letter like R: on Windows or a folder like /mnt/team on Linux.
• File system: the part of an operating system that turns raw disk space into files and folders, with names, sizes, and permissions.
• SMB (Server Message Block): the file-sharing protocol Windows uses [1].
• NFS (Network File System): the file-sharing protocol most Linux and Unix machines use [2].
• NAS (network-attached storage): a storage device that connects to a network and provides file access to clients [3], usually over SMB, NFS, or both.
• Client and server: the client is the machine that opens the connection and asks for files, and the server is the one that holds them and answers [1]. In the example, pc01 and pc02 are both clients, and nas01 is the server.

Where the file system lives: NAS, SAN, and local disks

Storage comes in three broad shapes, and the useful difference between them is which machine runs the file system:

Sources for the table: TechTarget’s comparison of the three [4] and SNIA’s definition of a NAS [3].

A SAN hands out raw disk space, called block storage, and the server that uses it formats it with its own file system, so to that server it looks like a local disk. A NAS keeps the file system to itself and hands out files. That’s why a NAS is the one to reach for when several machines need the same folder: they all send requests like “open budget.xlsx” to the NAS, and the NAS sorts out names and permissions in one place. The rest of this primer is about NAS-style sharing, SMB and NFS.

SMB

SMB is how Windows shares files: when you open \\server\share or map a network drive, the machine’s SMB client opens a connection to the SMB server on the other end [1]. A Windows PC, a Windows server, or a NAS can all be SMB servers, and Linux and macOS machines can be SMB clients or servers too. On Linux that’s usually Samba, an open-source implementation of SMB [5].

• Port: modern SMB runs over TCP port 445. Ports 137 to 139 belong to the old NetBIOS transport, which SMB 2 and later don’t use, and current Windows versions no longer open them for file sharing by default [6].
• Versions: client and server agree on the highest dialect both support. SMB 3.1.1 is current on Windows 10 and Windows Server 2016 and later [1].
• Logging in: the client connects as a user, usually a Windows or domain account, with Kerberos or NTLM [7].
• Encryption: SMB 3.0 and later can encrypt everything on the connection, per share, for a whole server, or when a client maps a drive. It protects data in transit, not on disk [8].

Keep port 445 off the internet

In 2017 the WannaCry ransomware spread between machines by connecting to TCP port 445 and exploiting a vulnerability in SMB version 1, and CISA’s advice at the time was to block SMB at the network boundary, port 445 and the old NetBIOS ports with it [9]. Microsoft gives the same advice today in both directions: block TCP 445 inbound from the internet, and outbound to the internet too, unless a specific cloud service needs it [6]. A file share that has to be reached from somewhere else is reached over a VPN or another private connection (reaching private resources covers the options), never by opening 445 to the world. Microsoft also says to remove SMB 1.0 wherever it’s still installed [8].

NFS

NFS is the Unix side’s equivalent. A Linux machine mounts an export, a folder the NFS server shares, into a local folder, and from then on programs use it like any other directory. The line in /etc/fstab that mounts one at boot looks like this [10]:

nas01.example.com:/exports/team  /mnt/team  nfs  defaults  0 0

• Port: NFS uses TCP port 2049. With NFS version 4 on that standard port, the client doesn’t need a separate lookup service to find the server’s NFS port, which is what lets it pass through a firewall with a single rule [2].
• Who is the user: the default security setting, sec=sys, sends the user’s Unix user and group numbers, and the server trusts the client machine to have checked them [10]. That’s only reasonable on a network where every machine that can reach the server is trusted.
• Kerberos: sec=krb5 proves each user’s identity with Kerberos, krb5i also protects every request from tampering, and krb5p encrypts the traffic as well [10], [2].

Which way the connections go

Arrows point from the machine that opens each connection. Both PCs connect to the NAS, and the NAS never connects to either of them.

Each arrow is one connection, opened by the machine at its tail to a port on the machine at its head, and the replies come back over that same connection. Written out one row per connection:

The NAS only ever answers. If anything sits between these machines that filters traffic, those two rows are all it needs to allow.

Checking it from a client

First check that the port is reachable at all, before worrying about permissions. On pc02, nc -z tries to connect without sending anything [11]. On Windows, Test-NetConnection has a shortcut for the SMB port [12]:

nc -vz nas01.example.com 445

Test-NetConnection nas01.example.com -CommonTCPPort SMB

Then mount the share. On Linux, mount -t cifs mounts an SMB share and username= sets the account [13]. On Windows, New-SmbMapping maps it to a drive letter, and -RequirePrivacy $true insists on SMB encryption [7], [8]:

sudo mount -t cifs //nas01.example.com/team /mnt/team -o username=pc02user

New-SmbMapping -LocalPath R: -RemotePath \\nas01.example.com\team -RequirePrivacy $true

To see which shares a server offers before mounting anything, smbclient -L lists them, with -U for the account to ask as [14]:

smbclient -L nas01.example.com -U pc02user

If the port check fails, the problem is the network path, or something on it blocking the port. If it succeeds and mounting fails, the problem is the account, its permissions on the share, or an encryption or version setting the two ends can’t agree on.

References

Every source cited across the primers is collected on one page.