📁 Managing Manila Shared Filesystems in OpenStack

Cinder gives you block volumes that attach to exactly one instance. That covers most workloads, but every cloud eventually hits the request that block storage can’t answer: “I have twelve web servers and they all need to read and write the same directory.” That’s a shared filesystem, and in OpenStack that’s Manila.

I’ve run Manila in production for years, and the honest summary is this: the service itself is straightforward once you understand share servers and access rules. The trouble is always the back end you bolt onto it. Here’s how I keep it sane.

What Manila actually gives you

Manila provisions file shares — NFS or CIFS — and hands tenants an export location they mount from any instance on the right network. The mental model:

• A share is the filesystem itself, sized in GB, with a protocol (NFS or CIFS).
• A share network ties the share to a Neutron network/subnet so tenant traffic stays isolated.
• A share type maps to a back end and a set of capabilities (DHSS true/false, snapshot support, thin provisioning).
• Access rules control who can mount it — by IP, by CIDR, or by user for CIFS.

The single most important decision is DHSS: driver handles share servers. With driver_handles_share_servers=True, Manila spins up a dedicated share server (often a service VM) per share network. That gives you hard multi-tenant isolation but a lot of moving parts. With DHSS false, you point at a pre-provisioned back end and skip the per-tenant servers. For most internal private clouds I run DHSS false — fewer service VMs to babysit, and the network isolation is handled elsewhere.

Creating your first share

Define a share type, then create the share against it:

# Create a share type backed by your generic/NetApp/CephFS driver
openstack share type create default_share_type False \
  --description "NFS, DHSS off"

# Create a 50GB NFS share
openstack share create NFS 50 \
  --name web-assets \
  --share-type default_share_type

# Watch it go available
openstack share show web-assets -c status -c export_locations

Once it’s available, grant access and mount it. Access rules are explicit by default — a share with no rules is reachable by nobody, which is exactly the safe default you want:

# Allow a CIDR to mount read-write
openstack share access create web-assets ip 10.0.5.0/24 --access-level rw

# On the instance
sudo mount -t nfs 10.0.5.30:/shares/share-abc123 /mnt/web-assets

The CephFS back end is where I’d start today

If you’re choosing a back end now and you already run Ceph for Cinder and Glance, use the CephFS native or NFS driver. You reuse the cluster you already operate, you get snapshots, and you skip the service-VM overhead of the generic driver. The manila.conf back end stanza is small:

[cephfsnfs]
driver_handles_share_servers = False
share_backend_name = CEPHFSNFS
share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
cephfs_protocol_helper_type = NFS
cephfs_conf_path = /etc/ceph/ceph.conf
cephfs_auth_id = manila
cephfs_cluster_name = ceph
cephfs_nfs_cluster_id = mynfscluster

The generic driver (NFS service VMs running on Cinder volumes) works, but it’s the one I’ve had the most 3am pages from: a service VM dies and a tenant’s shares go dark. CephFS pushes that durability problem down to Ceph, which is already designed for it.

Snapshots and the replica trap

Manila snapshots are crash-consistent, not application-consistent — quiesce your app before you trust one as a database backup:

openstack share snapshot create web-assets --name pre-deploy-2026-06-14
openstack share create NFS 50 --snapshot pre-deploy-2026-06-14 --name web-assets-restore

Share replication is tempting for DR, but the back end has to actually support it (replication_type in the share type). Set up a dr or readable replica only if your driver advertises the capability — otherwise the share type create succeeds and the first replica request fails confusingly.

The failures I actually see

After years of running this, the recurring incidents cluster into three buckets:

1. Mount hangs, not errors. NFS clients hang rather than fail fast. When a tenant says “the share is broken,” check the export location is still served and the access rule still matches the client’s current IP — floating IP changes silently break IP-based rules.
2. Share-server sprawl (DHSS true). Every share network gets a service VM. Tenants create dozens, nobody cleans up, and your compute fills with idle Manila service VMs. Audit with openstack share server list regularly.
3. Capacity reported wrong. Thin-provisioned back ends over-report free space. Manila’s scheduler trusts the driver’s capacity stats, so a lying back end leads to over-commit. Watch max_over_subscription_ratio and reserve real headroom.

A quick AI prompt I keep handy for the mount-hang case: paste the access rules, the client IP, and the export location, and ask for the most likely mismatch. It catches the floating-IP-changed case faster than I do at 3am. I keep a few of these in our prompt library.

Where to go next

Manila rewards you for picking a back end you already operate and keeping access rules tight and explicit. Start with DHSS false on CephFS, treat snapshots as crash-consistent, and audit share servers before they sprawl. For more OpenStack operations guides — Cinder, Neutron, and the rest of the storage and networking stack — see the OpenStack category.

Commands and configs here are starting points. Validate share types and access rules against your own back end before exposing shares to tenants.