Roadrunner SMB™ — Known Limitations

Last Updated: 2026-06-14

This document describes known limitations, constraints, and explicitly unsupported features in the current release. Read this before deploying for production use.

Deployment and Topology

Cluster size (1–4 nodes)

Supported deployment size: 1–4 nodes. Roadrunner SMB supports configurable 1–4 node deployments. A 1-node deployment is intended for evaluation, trial, and non-HA use. Multi-node deployments provide high availability for production workloads.

Set the initial count at deploy time via CloudFormation® Cluster Node Count (ClusterSize). After deploy, change cluster size from the Admin UI Cluster page using the Customer Cluster Node Target slider (1–4) and Apply, or by updating Cluster Node Count on the parent stack in CloudFormation. Resize triggers a stack update; ASG and ECS converge asynchronously.

Deployments outside 1–4 nodes are not tested and not supported.

Cluster resize behavior

• Admin UI: The slider range is 1–4 only — scaling to zero is not available from the UI (use stop/start flows instead).
• In progress: If a stack update is already running, Apply returns an error until it completes.
• Rollback: Failed resizes roll back via CloudFormation; refresh the Cluster page after ~15 seconds if the target reverts.

EC2 hosts vs ECS tasks

At steady state, ECS desired task count and ASG desired capacity both equal ClusterSize — one Roadrunner SMB task per EC2 host. ASG max size is ClusterSize + 1 to allow a temporary extra host during rolling updates; capacity returns to ClusterSize when updates complete. See Deployment Guide — EC2 hosts and ECS tasks.

Dual-AZ vs Single-AZ

Dual-AZ (two private subnets in two Availability Zones) is required for production high availability. Single-AZ deployment is supported for evaluation, development, test, and other non-critical / non-production workloads — it does not provide AZ-level fault tolerance.

No cross-region or DR support

Roadrunner SMB is a single-region deployment. Cross-region replication and disaster recovery configurations are not supported.

One appliance per AWS® Region

Only one Roadrunner SMB appliance per AWS Region per account is supported. Marketplace launch sets cluster ID rrsmb-prod for DynamoDB® and cluster resources; a second stack in the same Region is not supported.

Active Directory®

Single domain only

One Active Directory domain per deployment. Cross-domain trust scenarios are not supported.

Leave Domain not supported

Leaving the Active Directory domain from the Admin UI is not supported. To change domain membership, use Reset Appliance, which re-runs First-Time Setup for product configuration while retaining customer shares, EFS data, and ACLs in DynamoDB. Use the recovery secret to authorize First-Time Setup after an Appliance Reset.

Guest access not supported

All SMB access requires Active Directory authentication. Guest or anonymous access is not supported.

SMB Protocol Features

The following SMB features are not supported in the current release:

Byte-range locking — same-client multi-handle edge case

Roadrunner SMB implements SMB byte-range locking and has been validated across multi-client and multi-session scenarios under normal workloads.

In a specific edge case — multiple file handles opened concurrently from the same client process — locking conflict detection may behave differently from a native Windows® file server. This is a consequence of POSIX advisory locking semantics on Amazon EFS® (NFS): POSIX advisory locks are enforced per process, so a single process opening the same file twice can acquire what Windows would consider conflicting locks.

Impact: This affects applications that open multiple handles to the same file within a single process and rely on byte-range lock conflicts between those handles. This pattern is uncommon in typical user-driven, VDI, or departmental file share workloads. Data integrity is not affected; the behavior is a protocol-level semantic difference, not a correctness defect for real-world multi-user concurrent access.

Workloads not affected: All normal multi-user scenarios where different users or client machines hold conflicting locks are coordinated correctly by CTDB across all cluster nodes.

Oplocks and durable handle replay

Roadrunner SMB does not grant batch oplocks (opportunistic locks) or support durable handle replay semantics. Amazon EFS (NFS) does not provide the server-side change notification guarantees that batch oplocks require, so Samba correctly declines to grant them on an NFS backend.

Impact: Applications that depend on durable handle replay for session continuity after a brief network interruption (a capability specific to Windows-native file servers with persistent handle support) will not benefit from that mechanism. Normal SMB session reconnection is supported. File data integrity is not affected.

Networking

Admin UI transport

Marketplace: Use the AdminUIUrl CloudFormation output in a browser — HTTPS on port 443 on the stack’s Network Load Balancer. The NLB terminates TLS; traffic from the NLB to RRSMB tasks uses internal paths (including port 8888 on tasks), which is not the normal customer-facing instruction.

Restrict Admin UI access with AdminIngressCidr on the nested stack. That parameter controls inbound 443/TCP on the NLB security group (typical name rrsmb-<EnvironmentName>-nlb). Do not change the node security group (rrsmb-<EnvironmentName>-nodes) or AdminCidr expecting to limit Admin UI — AdminCidr is for Prometheus (9090) and SSH ops (22222) on cluster nodes only.

Recommendation: restrict AdminIngressCidr to trusted administrator source networks (default is 0.0.0.0/0). See Security overview — Restricting Admin UI access.

NLB DNS used for share paths

Shares are accessed via NlbDnsName on TCP/445 from networks allowed by SmbClientCidr (default private ranges such as 10.0.0.0/8 — not the public internet unless you widen it). Customers who require a custom DNS name should create a CNAME or alias record pointing to the NLB DNS name.

AWS Marketplace billing and customer EFS

What is metered

Roadrunner SMB reports usage to AWS Marketplace on two dimensions:

Billing is pay for hourly consumption use — $0.10 per ShareHour and $0.00007 per ManagedStorageGBHour. Charges accrue only while shares are active and EFS storage is mounted.

Entire EFS filesystem is billed (not share folder size)

For each share-mounted EFS filesystem, Roadrunner SMB queries Amazon EFS DescribeFileSystems and meters the total filesystem size (SizeInBytes) for that hour. Billing is not limited to data stored under the share’s access-point path — the whole filesystem counts.

Planning tip: If you attach an existing EFS filesystem that already contains data, Marketplace ManagedStorageGBHours will reflect the full filesystem size, not only new files written through the share. Size existing data and growth accordingly before mounting production filesystems.

One filesystem, multiple shares — billed once

Several SMB shares may reference the same EFS filesystem (different access points or paths). ManagedStorageGBHours counts each unique filesystem once per hour, not once per share.

Customer-owned EFS filesystems and access points

Roadrunner SMB does not create the Amazon EFS filesystems or access points used for customer SMB shares. You (or your platform team) must:

1. Create the EFS filesystem and access point(s) in your account.
2. Select them in the Admin UI when creating a share.

We recommend leaving EFS filesystem defaults unchanged (for example Elastic throughput and general-purpose performance mode) unless your AWS account standards require otherwise. Changing throughput mode, lifecycle, or other filesystem settings can affect performance and AWS infrastructure charges separately from Marketplace metering.

Performance

EFS/NFS backend limitations

Roadrunner SMB stores share data on Amazon EFS (NFS). Some file operations have different semantics on NFS compared to a native NTFS® filesystem:

• $QUOTA virtual file is not supported (EFS has no quota enforcement)
• NULL DACL behavior differs from native NTFS
• Some timestamp precision differences may be observed

These are fundamental EFS/NFS backend constraints and are not correctable at the Samba configuration level.

No file data caching

File data read/write operations are not cached; performance depends on EFS throughput and latency. Use EFS Elastic throughput mode (default) for best performance.

Monitoring and Metrics

Cluster metrics are aggregated, not per-node

The Admin UI shows cluster-wide aggregate metrics collected across all active nodes. Per-node metric drilldown is available via the Prometheus endpoint on each node (port 9090 on the task ENI) for advanced diagnostics.

No external metrics integration

There is no built-in integration with Grafana, Datadog, CloudWatch Metrics, or other external platforms. Raw Prometheus metrics are exposed per-node on port 9090.

Admin UI Configuration

Some settings are environment-variable only

The following configuration items are only changeable via CloudFormation environment variables; they are not exposed in the Settings page:

• Container CPU/memory limits
• EFS throughput mode
• Log level (not exposed in Admin UI; configure at deploy time or use CloudWatch for log access)
• CTDB tuning parameters

Software Updates

Automatic rolling updates

Roadrunner SMB supports automatic rolling updates driven by in-appliance release discovery:

Cluster nodes use standard, unmodified Amazon Linux 2023 EC2 instance AMIs with Roadrunner SMB host utilities installed at bootstrap. ECS and ASG perform rolling replacements sequentially to maintain high availability when two or more cluster nodes are configured. A single-node deployment will experience a brief interruption during an update.

Release discovery and scheduling

On the stable channel (Marketplace default), the auto-updater polls the configured release ECR repository about every 90 seconds. A build is offered only when its immutable tag and digest appear in the seller-published approved release manifest (approved.json). When a newer approved release is detected and automatic updates are enabled, the appliance schedules a CloudFormation update for the next local midnight after detection — the start of the next calendar day in the deployed AWS Region’s timezone (Region-local midnight, not the operator’s desktop timezone).

Operator controls (Admin UI Software Update page):

• Apply latest approved version — update now (immediate manual apply; does not wait for midnight)
• Defer — postpone a scheduled update by 24 hours per click
• Automatic updates toggle — disable auto-detection and midnight scheduling (manual apply still available)

Stack parameter UpdateScheduleOverride=immediate applies auto-detected updates immediately instead of at midnight local.

Change control: Review release notes before allowing production updates when operational change control is required.

Support

Support report required for assistance

When contacting support, generate and download a Support Report from the Admin UI Support page and attach it to your request. First-line support requires the report to begin triage. Reports are not uploaded automatically.

Early-customer support SLA

Initial response time: best effort within 1 business day. Formal SLA: to be published.

References

• Quick Start Guide
• Deployment Guide
• Frequently Asked Questions
• Support & Troubleshooting