Storage
Intermediate 11 min read Storage

File Storage Shares

A shared filesystem many machines can mount

File storage (EFS, Azure Files, Cloud Filestore) offers a POSIX/NFS or SMB share many instances mount simultaneously — the shared-disk layer object and block storage can't provide.

EFSNFSSMBAzure FilesFilestoreshared file system
Prerequisites: Block Storage Volumes
Before we start

What you will learn

  • Explain when a shared file system beats object or block storage
  • Mount cloud file shares on VMs/containers
  • Choose NFS vs SMB per workload and OS
In 60 seconds

Cloud file services present a network filesystem (NFSv4 or SMB) that any attached instance mounts. Multiple readers/writers share POSIX semantics — handy for shared code, home dirs, and stateful batch that prefers files over objects.

Introduction

What is this?

AWS EFS: managed NFSv4, scales automatically (elastic), mounts in many VPCs/AZs via mount targets. Azure Files: managed SMB3 (and NFS preview) with identity-based access and caching. GCP Cloud Filestore: NFS with provisioned capacity tiers (basic, high-scale, enterprise). Access is via mount points the guest OS sees as normal directories.

Motivation

Why do you need it?

  • Shared-writers: object storage has no 'append to one log from many writers'.
  • POSIX semantics let legacy apps work unchanged over mount points.
  • Containers can share config/code/volume mounts (read-only for scale-out).
  • Consistent backup point: snapshot the share once vs per instance.
Think about it

Mental model

Imagine

A company kitchen shared by every floor

Think of

Network file share

Everyone reads the same menu and fills the same fridge (shared state) — coordinating rules (POSIX locks, permissions) keep the kitchen sane across all users.

Mechanics

How it works

  • A mount target/gateway exposes the share over the VPC at a DNS name/IP.
  • Guests mount (EFS via amazon-efs-utils NFSv4.1; Filestore via standard nfs mount; Azure Files via SMB).
  • IGP: security groups/NSG/firewall rules must allow the NFS/SMB port from the instance's subnet.
  • Throughput modes (EFS: bursting/elastic; Filestore tiers) shape latency/cost.
  • Backups: EFS backup, Azure Files snapshot, Filestore backups at the share level.

Shared mount topology.

File share
Mount target
Instances
Shared data
Hands-on

Examples

Mount a shared filesystem

Mount a shared filesystem
# AWS EFS (one-time mount helper)
sudo apt-get install -y nfs-common amazon-efs-utils
sudo mkdir -p /shared
sudo mount -t efs fs-12345678 /shared
# GCP Filestore
sudo mount -o rw,nconnect=8,noresvport   <filestore-ip>:/vol1 /shared
# Azure Files via SMB
sudo mount -t cifs //<storage>.file.core.windows.net/share /shared \
  -o vers=3.0,username=<acct>,password=<key>,uid=1000,gid=1000

Standard mount commands; pick the protocol and endpoint per provider.

Real world

In production

  • A web farm shares a read-only /code mount for a stateless app that reads templates.
  • A CFD batch cluster keeps scratch results on a shared Filestore namespace.
  • Azure Files provides a home directory share to AAD users with ACLs via entitlement.
Guidelines

Best practices

  • Scope mounts to a private subnet and lock NFS/SMB ports in security groups.
  • Read-mostly workloads use read-only mounts to cut write contention.
  • Use access points/paths to namespace projects cleanly.
  • Watch throughput: shared bursts cap; separate hot from archive shares.
Watch out

Common mistakes

  • Using shared filesystems where object storage is simpler (public content, huge files).
  • Opening NFS/SMB to the internet (only via VPN/VPC + firewalls).
  • Not sizing Filestore capacity tiers — mischoice causes throttling.
  • Mounting read-write everywhere then hitting split-brain-ish concurrent-write corruption.
Root cause analysis

Common issues

Error
Cannot mount: connection timed out
Root cause

Network path blocked (SG/NSG/route) or mount target in another AZ

Fix

Create mount targets in each AZ your instances run in; allow 2049/445 inbound.

Error
Extremely slow writes
Root cause

Bursting exhausted on burstable throughput tiers

Fix

Switch to elastic/standard throughput or split writes across more mount points.

When things break

Debugging tips

  • Mount hangs: check SG/NACL for NFS 2049 or SMB 445, then verify the mount target IP is reachable.
  • Check for lock/lease timeouts: 'nfsstat' and dmesg show server-unreachable symptoms.
  • Azure Files: unexpected denies → check identity vs key access and SMB multichannel settings.
  • Perf dips: monitor throughput limits per mount target and file count (inodes count on Filestore).
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

Which protocol does AWS EFS expose?

Go deeper

Official documentation

AWS — EFS
docs
Azure — Azure Files
docs
GCP — Filestore
docs