3 NFS and SMB access to object storage is attractive for obvious reasons. Many applications and users only know how to work with file shares, yet object storage offers better scale, durability and cost for large volumes of unstructured data. Putting a file interface in front of object storage seems to offer the best of both. In practice, it works very well for some workloads and poorly for others, because files and objects behave differently. Understanding those differences avoids disappointing deployments. This article explains the ways to provide file access to object storage, what works well, what does not and how to test before committing. For the strategic context, see our hub on when object storage can replace NAS, and for a technical deep dive, see a file system over your S3 store. Ways to provide file access to object storage Built-in protocol support Some object storage platforms provide NFS or SMB access directly, mapping files to objects in buckets. The quality of semantics and performance varies widely between implementations. File gateways Gateways present SMB or NFS shares, cache data locally and store it in object storage, usually in their own format. They are designed for user file shares and multi-site collaboration. See what a cloud file gateway is. Client-side mounts Tools on client machines mount buckets as local file systems using FUSE or similar mechanisms. They are convenient for data science, scripts and simple workflows but often provide limited POSIX semantics. File system tiering High-performance or NAS file systems tier data to object storage while keeping the full file system in front. Users get true file semantics; object storage holds capacity. See parallel file system tiering to object storage. Why files and objects behave differently Whole-object writes: objects are written in full and replaced, not modified in place. Updating a few bytes of a large file means rewriting an object or managing multipart pieces. No real directories: object storage has a flat namespace with key prefixes. Directories are simulated, so renaming a directory means copying and deleting every object under it. Limited metadata: file permissions, ownership, extended attributes and timestamps must be mapped to object metadata or a separate database. No native locking: file locking for concurrent access must be implemented by the access layer. HTTP latency: each object operation is an HTTP request, adding overhead compared with local file system calls, especially for small files. What works well Write-once, read-many data: media, images, scientific data, archives and documents that are written once and read later. Large sequential reads and writes: copying files in, streaming them out and processing them sequentially. Archive and backup shares: applications that write files and rarely change them. Ingest landing zones: instruments, cameras or applications that drop files into a share for later processing. Read-mostly analytics: tools that read large files sequentially. User shares through gateways, where caching and gateway logic handle interactive behavior. What does not work well In-place updates: databases, virtual machine images and applications that rewrite parts of large files. Frequent appends: log files written line by line. Heavy small-file metadata activity: builds, source code trees and applications that create, stat and delete many tiny files. Directory renames on large trees: operations that are instant on NAS can take a long time on object storage. Strict locking: multi-user editing of the same files without a gateway that manages locks. Hard links, special files and some POSIX features. For these workloads, NAS or a true file system remains the better home. Dual access: file and S3 at the same time Some solutions let the same data be accessed through file protocols and directly through S3. This is powerful, for example letting users drop files in a share while pipelines read them via S3, but it requires care: Consistency: changes through one interface must be visible through the other promptly. Metadata: file permissions may not translate to S3 policies, and vice versa. Naming: file names with special characters or deep paths must map cleanly to object keys. Locking: S3 clients ignore file locks. Define which interface is authoritative for each workflow and test both directions. Performance considerations Caching in gateways or clients dramatically improves interactive performance. Large files perform far better than many small files. Parallelism: many concurrent operations hide per-request latency. Network: bandwidth and latency between clients and object storage directly affect throughput. Security and permissions Map users and groups from directory services to the file access layer, and decide how file permissions relate to bucket policies. Avoid giving broad S3 credentials to file access services; scope them to specific buckets. Audit access at both the file and object layers. See storage security best practices. Workload examples Video surveillance archives Video management systems that write recordings as large files and rarely modify them work well over file access to object storage, though native S3 support is better where available. See VMS archive to S3 object storage. Backup applications Backup software that writes large backup files to an NFS or SMB target often works, but many backup products now support S3 directly, which is usually more efficient and enables object lock. Scientific and imaging data Instruments that drop large files into a share work well, with pipelines then reading data over S3. Small-file outputs, such as thousands of tiny images per experiment, may need bundling. Home directories and office shares Interactive editing of documents with frequent saves and locks generally needs a gateway with caching and lock management rather than a direct protocol layer. Software builds and code repositories These generate huge numbers of small file operations and belong on NAS or local storage. Migrating applications from NAS to file-on-object Before moving an application’s data, review how it uses files: does it update in place, rename directories, rely on locks or create many temporary files? Check vendor guidance for supported storage. Run the application in a test environment against the file-on-object layer for a representative period, including peak loads and maintenance tasks such as indexing or cleanup jobs. Many issues only appear under real usage. The better long-term path: native S3 Where applications can be updated, native S3 access usually outperforms file emulation and unlocks object storage features such as metadata, lifecycle rules, versioning and object lock directly. Many organizations use file access as a bridge, moving applications to native S3 over time as vendors add support. Track which applications support S3 and plan migrations as they become available. How to test before committing Run the real application against the file interface, not just copy tests. Measure performance for typical file sizes and operations. Test renames, deletes, locking and concurrent access. Test behavior during object storage node failures. If dual access is planned, test consistency both ways. Verify permissions, ownership and timestamps are preserved as needed. Operating file access layers Monitor the file access layer separately from object storage: request latency per operation type, cache hit rates, error rates and the number of open files and locks. Problems often appear first as slow metadata operations, such as directory listings, before throughput drops. Keep protocol layers and gateways updated, since performance and compatibility improve over time. Checklist: NFS and SMB access to object storage Classify workloads by access pattern: write-once, read-mostly, in-place updates, small files. Choose built-in protocols, gateways, client mounts or tiering per workload. Keep in-place update and small-file workloads on NAS. Use gateways with caching for interactive user shares. Define authoritative interfaces for dual access. Size network and caching for performance. Map permissions and scope credentials. Test real applications, failures and concurrency. Putting it together NFS and SMB access to object storage works well for write-once, read-mostly, large-file and archive workloads, and for user shares when a gateway provides caching and locking. It works poorly for in-place updates, heavy small-file metadata activity and large directory renames. Match the access method to each workload, test with real applications and keep a NAS or file system for the data that genuinely needs full file semantics. Frequently asked questions Can object storage be accessed over NFS or SMB? Yes, through built-in protocol support, file gateways, client-side mounts or file system tiering, each with different capabilities. What workloads work best with file access to object storage? Write-once, read-mostly data, large files, archives, backup shares and ingest landing zones. Why are directory renames slow on object storage? Because directories are simulated with key prefixes, renaming one means copying and deleting every object beneath it. Can databases run on object storage via NFS? Generally not well, since databases depend on in-place updates and low latency. Can the same data be accessed via file and S3? Some solutions allow dual access, but consistency, permissions, naming and locking must be tested carefully. Further reading See when object storage can replace NAS, cloud file gateways, moving cold data off NAS filers, distributed office file sharing and a file system over your S3 store.
