securetools.live • November 2026File Sharing Permissions Explained: View, Edit, Download, and Expiry
File sharing permissions are the single most consequential layer of file security — and the one most frequently misconfigured. Four dimensions matter: the role (viewer, commenter, editor, owner), who it applies to (named user, group, link holder, public), the scope (file, folder, inherited), and the time bound (permanent, expiring, revocable). This article explains each dimension, how it works in Google Drive, OneDrive, and Dropbox, what download restrictions and link passwords actually prevent, how inherited permissions quietly produce over-exposure, and the limits of permissions as a security control. It includes a permission matrix mapping each control to the specific risk it addresses, and a list of the misconfigurations that cause most real incidents.
Permissions decide what each person can do with a file. Everything else about file sharing — encryption, authentication, audit — matters, but if permissions are wrong, the rest cannot save the file. Teams that experience a sharing incident usually traceable to a permission mistake rather than a cryptographic failure.
This article is a plain-English explanation of how file sharing permissions work in the three platforms most small businesses use: Google Drive, Microsoft OneDrive, and Dropbox. The terminology differs slightly between them, but the underlying model is similar enough that the mental model transfers.
The Four Permission Dimensions
Every permission can be described by four questions:
- Role. What can the holder of this permission do? View, comment, edit, own.
- Subject. Who holds it? A named user, a group, anyone with the link, anyone on the internet.
- Scope. What does it cover? A single file, a folder, inherited across subfolders.
- Time. How long does it last? Permanent, expiring on a date, revocable manually.
A sharing decision is the intersection of these four. "Editor access to the Q4 budget folder for the finance team, with manual revocation when a member leaves" is a complete permission statement. "Shared with the client" is not — it leaves three of the four dimensions ambiguous.
Viewer Permissions
The viewer role allows reading the file but not changing it. On Google Drive, viewers can see, print, download, and copy by default — three actions that produce persistent local copies. The sharing dialog has a specific toggle to disable download, print, and copy for viewers; it is not on by default. On OneDrive and SharePoint, the equivalent is "block download," applied through the Share pane. On Dropbox, viewer links can be configured as view-only through the link settings.
Viewer is the right default for anyone who does not need to edit. If a reviewer only needs to read a document, give them viewer; if they need to leave feedback, upgrade to commenter. Starting with viewer and upgrading on request is safer than starting with editor and discovering unexpected edits later.
Editor Permissions
The editor role allows changing the file content. In most platforms, editors can also change the sharing settings — adding other people, generating new links, or converting a restricted file into a public one. This is a frequently overlooked side effect: granting edit rights usually grants re-share rights.
For high-sensitivity collaborative files, both Google Drive and OneDrive have an advanced setting that restricts editors from changing permissions. This separates "can change content" from "can change who sees it," which is a useful discipline for shared folders holding sensitive material.
Owner and Admin Rights
The file owner has the strongest set of rights: delete the file, transfer ownership, permanently change permissions. In Google Workspace and Microsoft 365, admin accounts can additionally override user permissions and recover files from any user. This administrative reach is necessary for off-boarding and compliance, but it means admin credentials are a particularly high-value target.
Enforce MFA on every admin account, prefer hardware security keys for the privileged accounts, and limit the number of users with full admin rights. The companion guide to the enterprise file sharing security checklist covers administrative controls in more detail.
Internal vs External Roles
Platforms distinguish between users who belong to your organization (internal) and anyone else (external, often called guests). The distinction matters because internal users are governed by your SSO, MFA, and off-boarding policies; external users are not.
A common configuration is: internal users can create any sharing links; external users must be invited by email and verify through the sharing platform; public links require admin approval. This maps the permission model to the identity model and prevents the quiet accumulation of external accounts no one is tracking.
Group-Based Access
Granting access to a group — a mailing list, security group, or SSO group — scales much better than individual permissions. Changes to group membership automatically update file access, so onboarding a new team member or removing a departing one happens through one action in the identity system.
The tradeoff is reduced visibility: the file's sharing dialog shows the group name but not every member. If you need to answer "who exactly has access to this file," you have to combine the file's permissions with the current group membership. For high-sensitivity files, prefer named individual permissions, which make the access list immediately legible.
Inherited Permissions
A file inside a shared folder inherits the folder's permissions. This is the single most common source of accidental over-exposure. A file created in a client-shared folder is immediately accessible to the client, even if that was not the author's intent. Moving a confidential file into the wrong folder has the same effect.
To check effective permissions, open the file's sharing dialog and look at everyone listed, including inherited entries. On SharePoint, the "Advanced" share options show inheritance explicitly; on Google Drive, inherited sharing is visible but can be subtle. When restructuring folders, treat moving a file as a permission change — review access before and after.
Download Restrictions
A download restriction prevents the recipient from pulling a local copy of the file. On Google Drive, this is the "Viewers and commenters can see the option to download, print, and copy" toggle. On OneDrive, it is "Block download" in the Share dialog. On Dropbox, download settings sit under the link's edit options.
What download restrictions prevent: the recipient saving a persistent local file, printing to PDF through the normal interface, copying content directly. What they do not prevent: screenshots, screen recording, photographing the screen, re-typing content, or using OS-level accessibility tools to extract text. They are a meaningful control for routine confidentiality, not an absolute barrier.
For a more detailed walk-through on PDF-specific download blocking, see how to share a PDF without allowing downloads.
Link Passwords and Identity Verification
A link password is a shared secret that must be entered before the file opens. It converts a public link into a soft-gated one, with two important caveats: the password is only as strong as the delivery channel (sending it in the same email as the link defeats the purpose), and it does not identify the person entering it. Anyone who has the password can view the file.
Identity verification is a stronger alternative. Platforms can require the recipient to confirm an email address before opening (one-time code), authenticate through SSO, or create an account that persists. The right choice depends on the sensitivity and the recipient's willingness to engage. For most confidential sharing, email verification is a practical minimum.
Expiration Dates and Guest Access
Expiration is the quiet workhorse of permission hygiene. It makes stale access self-cleaning. On every platform, the default is often "no expiration," which guarantees long-tail exposure. Set an expiry on every external share, and configure guest access to require periodic re-authentication.
For organizations with a lot of guest accounts, platforms also expose automated reports: Microsoft 365 has guest access reviews in Entra ID; Google Workspace has external sharing reports in the admin console; Dropbox Business has team activity logs. Reviewing these quarterly turns up stale access that has survived multiple project closeouts.
Permission Matrix: What Each Control Actually Protects
| Control | Protects Against | Does Not Prevent |
|---|---|---|
| Named-recipient access | Link forwarding | Authorized recipient sharing their own device |
| Link password | Casual URL discovery | Password reuse or re-share |
| Expiration | Long-tail stale access | Downloads already taken |
| Download block | Casual file copies | Screenshots, photos, retyping |
| Watermarking | Anonymous leaks | Determined cropping |
| Edit restriction | Accidental content changes | Viewer-level copying |
| Admin audit log | Undetected incidents | Problems if never reviewed |
Common Misconfigurations
- Default link setting left as "anyone with the link."
- Editor role granted when viewer or commenter would do.
- Confidential files moved into client-shared folders without checking inheritance.
- Groups used for sensitive files, obscuring the actual access list.
- Password sent in the same email as the link.
- Guest accounts persisting indefinitely with no review.
- Download block treated as leak prevention.
The Limits of Permissions
Permissions enforce rules while the file is inside the platform. Once a copy exists on the recipient's device, no permission change affects it. A viewer who has downloaded a file keeps that copy forever. A collaborator removed from a folder cannot see the current version, but still has whatever they already saved.
This is why permissions pair with other controls: audit logs for post-fact investigation, watermarks for attribution, encryption for interception resistance, and expiry for long-tail cleanup. No single control is sufficient. The goal is a layered configuration where the failure of any one layer does not produce a catastrophic exposure.
For broader context on how permissions fit into an overall file-sharing posture, see the parent guide on secure file sharing for business and the operational walk-through on auditing external file sharing.
Frequently Asked Questions
A viewer can read the file but not change it or leave notes attached to it. A commenter can add inline comments and suggestions without editing the underlying content. In Google Workspace and Microsoft 365, commenter is a useful middle role for reviewers who need to leave feedback without accidentally overwriting content. For external clients, start with viewer and upgrade to commenter if feedback is required.
About the Author: Mohamed Siraj
Mohamed is the founder of SecureTools.live. He leads the team in building secure, compliant, and privacy-first directory tooling for software teams, finance professionals, and enterprise security leaders worldwide.