File sharing: what beginners should know in 2027

If you are new to this category, the confusing part is that one product is sold as the answer to three different problems. "File sharing" can mean keeping files available on all your devices, sending a document to someone outside your organisation, or storing everything the business has ever produced somewhere safe.

Those are three jobs. Products are good at different ones. Knowing which job you are buying for is most of the decision.

Three jobs, one product

Sync keeps a copy of files on your machine and on the provider's servers, and reconciles them. It is what makes your laptop, your phone, and your colleague's desktop show the same folder. Sync is the feature that generates the most day-to-day trouble, because it is the one doing something genuinely difficult.

Share hands access to a specific file or folder to a specific person, or to anyone holding a link. This is where the security decisions live.

Store is the long-term home for material that is not being actively worked on. Archives, records, finished work. Storage cares about durability, retention, and cost, and barely about convenience.

A product that syncs beautifully may have a crude permission model. A product with excellent governance may have a sync client that annoys everyone. Decide which of the three matters most to you before you look at anything, because the marketing will not distinguish them.

The permission model is the product

For business use, this is the part that actually differs, and it is worth learning the vocabulary because vendors use the same words to mean different things.

Inheritance. Whether a file's access comes from the folder it sits in. Almost always yes, and the interesting question is what happens when you move a file. Does it keep the access it had, or take on the access of its new location? Both designs exist. Both surprise people.

Named access versus link access. Named access means a specific account can open it. Link access means possession of the URL is the credential. Link access is enormously convenient and it is the mechanism behind most accidental exposure in this category.

Link scope. A link can be open to anyone, restricted to people inside your organisation, or restricted to named recipients who must sign in. Find out what the default is when someone clicks "share", because that default is what your organisation will mostly do.

Expiry and passwords on links. Whether links can be time-limited, and whether that can be enforced as a policy rather than left to each person's judgement.

View versus edit versus download. Preventing download is a weaker control than it sounds, anyone who can see something can photograph it, but it does stop casual copying and it does keep files out of other people's storage.

External and guest access. Whether people outside your organisation can be granted access at all, whether they need an account, and whether an administrator can see and revoke all such access from one place.

The single most useful question to ask of any candidate: can an administrator produce a list of everything currently shared outside the organisation? If the answer is no, you cannot govern it, no matter what the settings screen offers.

Links have an afterlife

A share link, once created, tends to outlive everything about the situation that produced it.

It keeps working after the recipient leaves their job, unless it was tied to a named account.
It keeps working after the project ends, unless it had an expiry.
It gets forwarded, pasted into other systems, and embedded in documents you do not control.
It survives being forgotten. Nobody revokes a link they no longer remember making.

Two consequences worth planning for. Set a sharing default that is restrictive and let people loosen it deliberately, because the reverse, a permissive default that people are supposed to tighten, does not happen. And schedule a review of external shares, because it is the only thing that removes the ones nobody remembers.

What the sync client does when things go wrong

Sync is easy when everything works. Evaluate it on its failure behaviour instead.

Conflicts. Two people edit the same file offline. Almost every product resolves this by keeping both and renaming one. Find out how it names the copy and whether anyone is told. The failure mode is silent: someone's work is preserved in a file nobody opens.

Deletion. Deleting a synced file deletes it everywhere, including from colleagues' machines. This is correct behaviour and it consistently shocks people. Know where deleted files go, how long they stay, and who can retrieve them.

Selective and on-demand sync. Whether you can choose which folders come down, and whether files can appear in your file browser without occupying disk space until opened. For anyone with a small drive and a large shared archive, this is not optional.

Bulk operations. What happens when someone drags a very large folder, or when a script writes thousands of files. Sync clients can saturate a connection or fall a long way behind, and a client that is silently behind is worse than one that stops with an error.

Filenames. Different systems disagree about which characters are permitted, how long a path may be, and whether upper and lower case are distinct. Files that break these rules get renamed, skipped, or refused. If your work involves long folder hierarchies or names generated by another system, test this deliberately.

Files that do not merge. Design files, drawings, and most binary formats cannot be merged. If two people edit one, someone's work is discarded. Products differ in whether they offer a check-out mechanism to prevent this. If your team works with such files, this is a top-tier requirement rather than a detail.

Versioning and the recovery question

Version history is the feature people assume they have and rarely test.

Ask three things:

How far back does it go, and does that depend on the tier?
Does it cover deletion as well as modification? These are frequently different retention periods.
Can you roll back a folder, or only a file? This matters more than anything else in the category, because the scenario you need it for is not "I overwrote a paragraph". It is "something changed or destroyed thousands of files across a shared area, and we need everything as it was on Tuesday morning". File-by-file restoration is not a recovery capability at that scale.

Test the third one during a trial. Delete a populated folder, restore it, and check whether the sharing permissions came back with the contents. Very often they do not, and rebuilding permissions across a restored archive is a substantial job.

How storage is counted

Get this straight before comparing prices:

Per seat or pooled. Per-seat allocations strand unused space with light users while heavy users hit a wall. Pooled storage lets the organisation absorb the variation, and for most businesses it is worth paying for.
Whose quota does a shared file consume? Usually the owner's. This produces the situation where one person's account is full because they created the team's shared area.
Do old versions count? Version history takes space. Sometimes it counts against your quota, sometimes it does not.
Do deleted files count while they sit in the recovery window?
What happens at the ceiling? Uploads refuse, sync stops, or you are billed for the overage. Only one of those is quiet, and it is not the one you want to discover during a deadline.

A trial that tells you something

Skip the sample files. Do this instead:

Sync a genuinely large real folder to a laptop with a small drive and watch what happens.
Create a deliberate conflict: two people editing the same file, one of them offline, then reconnect.
Share something with an outside collaborator and have them open it on their phone without an account.
Delete a folder with real structure and restore it, then check permissions.
Have an administrator produce a list of everything shared externally.
Move a file between folders with different permissions and see which permissions it ends up with.
Copy in a folder with awkward filenames (long paths, accented characters, punctuation), and read the error report.

Getting your files back out

Ask before you commit:

Can an administrator export everything for everyone, or must each user do their own?
Does the export preserve folder structure, ownership, sharing state, and version history, or only the current version of each file?
How long does a full export take at your volume, and is there a size beyond which it must be batched?
Are there limits or charges on bulk retrieval through the API?
After cancellation, how long is data kept and how long do you have to collect it?

What does not move with you

Files move. The things that do not move are:

Permissions, which usually have no equivalent on the other side and get rebuilt by hand.
Every share link ever issued, all of which die. Links live in emails, documents, and other people's systems, and you cannot find them all.
Version history, which is rarely carried across.
Original timestamps and ownership, which many transfers overwrite: a real problem if retention periods or date-based processes depend on them.
Anything embedded elsewhere, such as a file referenced from a document, a website, or another application.

Which is why the questions above are worth asking in the first week of an evaluation rather than the last week of a contract.

More on this site: file sharing security, setup notes, and how the alternatives compare.