Already running Samba or CTDB on Amazon EFS?
Amazon EFS is built for NFS — not native Windows SMB. Teams that want EFS economics with Windows clients often deploy a Linux Samba or CTDB gateway: mount EFS on EC2, export SMB, integrate Active Directory, and hope the cluster stays healthy under load. AWS even published a sample for this pattern — but it is sample code, not a product.
Why teams run Samba on EFS
The community pattern is well known: mount Amazon EFS on Linux, configure Samba (often with CTDB for HA), join Active Directory, and map shares from Windows. AWS documents this approach in the sample repo AWS sample: EFS Samba AD integration. That repository states plainly that the solution is not officially supported by the Amazon EFS team — if you have trouble deploying it, file an issue on GitHub, not an AWS Support case. The repo is archived (read-only) as of February 2026.
Where DIY Samba and CTDB break down on EFS
Metadata-heavy workloads — FSLogix profiles, login storms, directory enumeration — expose EFS latency through Samba. CTDB locking.tdb contention can stall clusters for minutes or hours. Teams hit Samba dfree / NFS quota timeouts that make Windows Explorer hang. ACL and idmap edge cases are yours to debug. HA, fencing, patching, and on-call — your team owns every failure mode.
Where do your Windows ACLs actually live?
The AWS sample configures Samba with vfs objects = acl_xattr, which stores each file's Windows security descriptor in a security.NTACL extended attribute. That works on ext4 or XFS — but Amazon EFS speaks NFS 4.1 and enforces POSIX permissions only: no NFSv4 ACLs, and no extended-attribute namespace for Samba to persist security.NTACL. The Windows ACL you set — per-user and per-group entries, inheritance, explicit deny — has nowhere durable to live, so access falls back to POSIX owner/group/other mode bits. The sample also isn't a cluster: its HA option runs independent Samba servers (no CTDB) behind Windows DFS, and even local identity mapping (idmap config * : backend = tdb) is per node. Nothing keeps Windows ACL semantics correct on one node — let alone consistent across several.
Roadrunner SMB takes ACLs off the filesystem entirely. A purpose-built Samba VFS module (rrsmb_acl_ddb) stores full NT ACLs in Amazon DynamoDB — regional, read by every node, and deduplicated by ACL content — so Windows permissions keep full fidelity and stay identical on every node, independent of EFS's NFS version or extended-attribute support. File bytes stay on EFS; the authoritative ACL lives in your DynamoDB table.
Patching on someone else's schedule
A personal or internal Samba/CTDB build is even less likely than a vendor product to have a structured vulnerability process — it's not anyone's maintained product, so nobody's job is to watch for CVEs against it. AWS doesn't scan it for you either; Amazon Inspector is opt-in and, even enabled, only reports findings — your team still triages, tests, and patches on its own timeline. Roadrunner SMB's appliance goes through AWS Marketplace's vulnerability scanning as part of normal listing maintenance, with security backports shipped as part of the regular release cycle (see the Release Notes).
Marketplace-supported stack on the same EFS data
Same EFS dataset. A maintained, Marketplace-supported SMB3 layer — with Elastic SMB™, automatic HA, and an Admin UI instead of hand-rolled Samba/CTDB operations.
Elastic SMB™ metadata acceleration
Patent-pending Samba VFS in-memory cache delivers fast metadata on EFS-backed shares. Absorbs login-storm load while preserving accurate Windows ACL semantics over SMB — not a speed-vs-correctness trade-off.
ECS-managed Samba/CTDB cluster
Amazon ECS runs and replaces unhealthy nodes automatically. Self-fencing (TCP/445 eligibility) prevents split-brain serving — NLB health checks steer traffic away from ineligible nodes. No manual cluster formation or CTDB recovery scripts.
Admin UI visibility & control
Browser Admin UI shows live cluster state — health, nodes, shares. Cluster size slider from 1–4 nodes (also set at deploy via CloudFormation ClusterSize). Support reports and billing status in one place.
Windows ACLs on DynamoDB
NT ACL metadata in Amazon DynamoDB in your account — authoritative file bytes stay on EFS. EFS stores POSIX permissions only, so DIY acl_xattr cannot persist true Windows ACLs; Roadrunner SMB keeps full NT ACLs in DynamoDB, shared by every node.
DIY Samba/CTDB vs. Roadrunner SMB
| Dimension | DIY Samba/CTDB on EFS | Roadrunner SMB |
|---|---|---|
| Operational ownership | Your team builds, patches, and on-calls the gateway — including watching for and responding to CVEs yourself | Marketplace appliance; ECS-managed lifecycle |
| Metadata / login storms | Manual tuning; raw EFS latency exposed | Elastic SMB™ VFS metadata cache |
| HA / failover | Manual CTDB ops, recovery scripts | ECS auto-replace; NLB health gating |
| Split-brain protection | Your fencing scripts and CTDB discipline | Self-fencing; ineligible nodes drop SMB |
| Cluster visibility | SSH, logs, CTDB status commands | Admin UI — live cluster state |
| Scale-out | Manual HA scripts / multiple EC2 instances | Admin UI slider or CFT — 1–4 nodes |
| Windows ACLs | acl_xattr writes security.NTACL — unsupported on EFS; ACLs degrade to POSIX bits, per node | Full NT ACLs in DynamoDB — shared by every node, deduplicated |
| Support path | Community lists / your team | Marketplace listing + Support Report |
Architecture depth: Product overview → · FSx for Windows comparison →
Technical architecture details
The GA architecture whitepaper covers Elastic SMB caching, cluster HA, self-fencing, DynamoDB ACL model, billing dimensions, and deployment topology — the engineering detail behind the managed stack above.
Frequently asked questions
Can Amazon EFS store Windows ACLs?
Not directly. EFS uses NFS 4.1 and enforces POSIX permissions only — no NFSv4 ACLs and no place for Samba acl_xattr to persist a security.NTACL descriptor, so DIY setups fall back to owner/group/other mode bits. Roadrunner SMB stores full NT ACLs in DynamoDB (via the rrsmb_acl_ddb VFS module), preserving Windows inheritance and deny semantics across every node.
Can Windows mount Amazon EFS directly?
No. Amazon EFS is NFSv4 — AWS documents that using EFS with Microsoft Windows–based EC2 instances is not supported. Teams typically re-export EFS over SMB via a Linux gateway (Samba) or use a managed SMB appliance like Roadrunner SMB.
Is the AWS Samba sample repo officially supported?
No. The AWS sample efs-samba-ad-integration-for-windows-access repository states the solution is not officially supported by the Amazon EFS team — contact GitHub issues, not AWS Support. The repo is archived and read-only.
Do I keep my EFS data?
Yes. Roadrunner SMB mounts your existing Amazon EFS file systems. Files remain standard objects in your account if you remove the appliance.
What about FSLogix and login storms?
Login-heavy VDI and profile workloads stress EFS metadata. Elastic SMB VFS caching is built for that pattern — the problem DIY Samba clusters most often hit without extensive tuning.
Replace DIY Samba with a supported appliance
Subscribe on AWS Marketplace, launch into your VPC, and complete First-Time Setup in the Admin UI. Same EFS data — managed SMB3, Elastic SMB, and automatic HA.