Cloud-based file system: shared drives, sync apps, and gateways

A cloud-based file system gives users or applications access to files and directories hosted on remote infrastructure. For an application that expects a shared drive, the important question is how it opens, changes, and locks those files. For a team sharing documents, browser access, editing tools, and guest permissions may matter more.

Those needs can lead to different products even when every product displays folders. This guide compares mounted file shares, file-sync applications, and gateways into object storage. Use it to decide which access model fits the work, then test the behavior that a familiar folder icon cannot show.

What do you need the file system to do?

Start with a normal working day. Identify who creates files, which applications change them, how others receive updates, and what happens when someone loses their connection. Record the operating systems, devices, office locations, and external collaborators involved. A department sharing PDFs has different requirements from several servers updating a common application directory.

Separate storage requirements from application requirements. Capacity describes how much data you can keep. File sharing describes how others reach it. File locking controls certain competing operations. Co-authoring coordinates edits inside a supported document. Backup provides a way to recover an earlier usable state. A service may provide several of these, but one does not establish the others.

Mounted shares, synchronized folders, and object gateways

Access model	What the user or application sees	Useful starting point	Main check
Managed file share	A network path or mounted directory, commonly through SMB or NFS	Applications and shared folders that depend on file-system operations	Protocol, permissions, locking, latency, and supported clients
Sync and collaboration app	A web interface, mobile app, or synchronized desktop folder	Document sharing and work across multiple devices	Conflict handling, offline copies, guest access, and editing integrations
File gateway or object-store mount	A file interface backed by objects and an additional translation layer	Workflows that need file access to data held in object storage	Supported operations, caching, metadata mapping, and write behavior
File server on a virtual machine	A familiar server and network shares hosted in a cloud environment	Software requiring a particular server configuration	Who patches, monitors, backs up, and recovers the server

“Cloud file server” and “online file storage” are used for several of these models. Ask for the actual client interface and deployment design. Moving a Windows file server into a virtual machine changes its location; it does not automatically turn it into a fully managed service or a browser-based collaboration tool.

Choose the access model around the workflow

Shared documents and external collaboration

If people mainly exchange documents, review a file-sharing application before provisioning a network file system. Test its browser interface, mobile access, sharing links, folder permissions, and the procedure for removing a former collaborator. Confirm which features belong to the plan you would buy.

Simultaneous document editing needs support from the editing application, storage integration, file format, and permissions. Microsoft's co-authoring documentation explains these dependencies. Two people being able to open a file does not prove they can safely edit it at the same time.

Applications that expect a shared drive

A legacy application may require a particular network path, Windows access control lists, or file-locking behavior. A Linux application may expect ownership, permissions, symbolic links, or operations provided through NFS. Write down these requirements before comparing storage prices.

Keep the application close to its data when frequent network round trips affect responsiveness. A share that works well for cloud servers in one region may feel slow when mounted from a distant office. Measure the actual task: opening a project, saving changes, scanning a folder, or completing a batch job.

Archives, uploads, and datasets

If an application already uploads and retrieves objects through an API, it may not need a file system. Object storage can hold media, backups, exports, and datasets without presenting a mounted share. Block storage is another model: it presents a volume to a host, which can put a file system on it. Neither is interchangeable with a shared file service merely because it can store the same bytes.

Use a gateway when its behavior solves a specific integration need. Amazon S3 File Gateway, for example, exposes NFS and SMB file access to objects in S3 and uses local caching. The gateway, cache, network connection, and object store all become part of the operational design.

Check protocols and file behavior before features

SMB and NFS support

SMB is a common starting point for Windows file sharing; NFS is common for Linux and Unix workloads. Support depends on the service, client, version, and authentication method. A product advertising both protocols does not mean every share or configuration provides both at once.

Azure Files offers managed SMB and NFS shares, with different client support. Amazon EFS provides NFS access for supported workloads. Google Cloud Filestore provides managed NFS file servers with service tiers that differ in capacity, performance, and resilience. Compare the documented configuration you intend to deploy.

Locks, renames, and concurrent writers

Test the operations your software uses, including opening an existing file, creating a temporary file, renaming it, and recovering after a client disconnects. Check whether another client sees an update when the application expects it. Where the software relies on locks, verify both conflict prevention and what happens when the client holding a lock fails.

A file interface over object storage can have different rules. Google documents that Cloud Storage FUSE is not POSIX compliant and does not support file locking. That is a limitation of that implementation, not a claim that all object-backed file systems behave identically. Check the chosen tool rather than assuming that a mounted directory provides every local file-system operation.

Metadata is part of the migration

File contents are only part of a working share. Ownership, group membership, access control lists, timestamps, links, and application references may also matter. A copy can preserve document contents while losing the permissions that made the source usable and safe.

Create a representative test set containing long paths, unusual characters, large files, small files, restricted folders, and the file types used by important applications. Check both successful access and deliberate access denial. Record unsupported names or metadata before a full migration starts.

Remote access and offline work need separate tests

A network mount is not a sync folder

Managed cloud file shares often use private network paths, VPNs, or dedicated connections. Internet connectivity alone does not make them accessible from every device. Confirm routing, DNS, firewall rules, authentication, and supported clients for each location.

A desktop sync app can keep local copies and send changes later, but offline behavior depends on the product and settings. An online-only placeholder may show a file name without containing its contents. Before a trip or planned outage, explicitly download the required files and test opening them without a network connection.

Hybrid caches have their own limits

Hybrid designs retain local file access while connecting to cloud storage. In Azure File Sync, Windows Server endpoints synchronize with Azure file shares; cloud tiering can keep only part of the data local. Azure File Sync supports SMB shares, not NFS shares.

For any cache-based design, test a file already present locally and one that must be retrieved from the cloud. Then test reconnection and conflicting changes. A local cache can improve responsiveness, but it is not evidence that every file remains available during an outage or that separate writers cannot conflict.

Protect access without assuming the cloud handles everything

Map people, groups, applications, and administrators to the actions they need. Distinguish the ability to manage the storage service from the ability to read its files. Review inherited permissions and service accounts, and test what changes when a user leaves the organization.

Protect administrator sign-ins with multifactor authentication where supported, and check the authentication path used by file clients separately. A browser sign-in protected by MFA does not describe every mounted client's access. Confirm encryption at rest and in transit for the selected protocol and configuration, plus who controls encryption keys.

For external sharing, test whether recipients must sign in, whether links expire, and whether access can be revoked. Record what audit logs capture and how long they are available. Our cloud storage security guide provides further questions for this review.

For sensitive data, establish where file data, backups, replicas, and relevant logs are stored, and who can access them for support. The European Data Protection Board's transfer guidance is relevant when personal data crosses borders. A provider certification or EU region should be assessed in its actual scope, alongside the organization's responsibilities.

Plan recovery independently of synchronization

A service can replicate a deletion just as efficiently as a useful edit. Redundancy protects against specified infrastructure failures; version history, snapshots, and backups address different recovery needs. Read the retention rules and check who can delete both working data and recovery copies.

Define how much recent work can be lost and how long restoration can take. Test a deleted folder, an unwanted bulk change, and recovery when normal administrator credentials are unavailable. CISA's ransomware guidance recommends protected backups, including offline encrypted copies, and regular recovery testing.

For the basic distinction, see our guide to cloud sync and cloud backup. Keep the recovery procedure, contact details, and required credentials accessible through an approved route that does not depend entirely on the failed service.

Compare the cost of usable access

Price per terabyte can hide the cost of making files usable. Managed file services may charge for stored or provisioned capacity, throughput, operations, snapshots, and transfers. Collaboration applications may charge by user, plan, or storage allowance. Gateways can add software, local cache, virtual machine, and maintenance costs.

The Amazon EFS pricing page illustrates why storage, throughput, storage-class access, and transfer need separate attention. Use current rates for the chosen region and configuration. Avoid comparing an object-storage capacity price with a file service or collaboration subscription as if they included the same work.

Cost question	Evidence to request
What is billed even when unused?	Minimum capacity, user commitments, provisioned performance, and retained snapshots
What grows with activity?	Requests, throughput, retrieval, and chargeable network traffic
What remains on premises?	Cache disks, servers, connectivity, licenses, and support
What does a recovery or exit cost?	Export volume, restoration capacity, temporary copies, and staff time

Compare a normal month, peak activity, and a full recovery or export. Include the period when old and new services run together. A lower infrastructure bill may still require more administration; a higher subscription may include functions the team would otherwise operate itself.

Where Hivenet's storage products fit

Store with Hivenet is the everyday-file and photo-backup product. Its public page describes file and folder sharing, access across devices, and online-only files. Evaluate the supported clients and sharing workflow against what your users need.

Hivenet Object Storage serves business workloads using S3-compatible tools. Its public offer includes free egress and a request-access route. These are distinct product paths; neither description should be treated as evidence of a managed SMB or NFS share, full POSIX behavior, or support for every desktop application's locking requirements.

A six-step acceptance test

Choose one representative team or application and use non-sensitive or appropriately prepared test data. Agree on measurable acceptance criteria before comparing results. For example, a project must open within the team's acceptable time, restricted folders must remain inaccessible to an unauthorized test account, and a restore must finish within the recovery target.

1. Map the work. Record applications, devices, users, file counts and sizes, access patterns, and required file operations.
2. Test everyday access. Open, edit, save, rename, and find files through the actual client and network path.
3. Test competing activity. Use two clients, create conflicting edits where appropriate, and check locking, visibility, and error handling.
4. Test interruption and recovery. Disconnect a client, restore a test folder, and confirm what happens to unsynchronized changes.
5. Check permissions and cost. Verify allowed and denied actions, revoke a test account, and compare measured usage with the estimate.
6. Test export and the changeover. Copy data and required metadata to another location, verify the result, and document the return to the old service if acceptance fails.

Before changing production access, name the authoritative copy and explain how final changes will be captured. Avoid leaving two writable locations without a supported synchronization or reconciliation process. Retain the old recovery path until the new workflow has passed its agreed checks and the retirement decision is approved.

Common questions

Is a cloud file system the same as cloud storage?

Cloud storage includes file, object, and block services, as well as applications built on them. A cloud file system provides file and directory behavior. A folder view in a web application alone does not tell you which file operations are supported.

Can it replace an office file server?

It can for suitable workloads. Confirm the protocol, identities, application behavior, network path, recovery process, and cost. Some teams benefit from a managed share; others need a collaboration application or a hybrid design.

Does cloud file storage provide unlimited capacity?

Services have quotas, capacity ranges, object or file limits, and performance constraints. Some scale automatically, while others require provisioning or changes to a service tier. Plan for expected growth using the selected product's current limits.

Will files work offline?

Only when the access model and configuration provide usable local copies. Test the required files while disconnected, then reconnect and verify how changes and conflicts are handled.