Drive Roles and Permissions Explained

Permissions are what make StretchDrive safe to use across a whole team. This article explains the role model in depth so you can grant exactly the right access — no more, no less.

The four roles

StretchDrive uses four roles, from least to most powerful:

• Viewer is read-only: open, preview, download.
• Commenter adds the ability to leave comments (in the connected editors) without changing the file itself.
• Editor is the collaborator role: edit content, upload new versions, rename, move, create subfolders, and share with others.
• Owner is full control, including deleting and permanently deleting.

Where roles come from

Your effective role on any file or folder is the highest of several sources:

1. Ownership. The person who created or uploaded a resource is always its Owner.
2. Workspace role. Workspace owners and admins have Owner-level access across Drive for governance.
3. Direct grants. Permissions someone assigned to you specifically, to a group you belong to, or to the whole organization.
4. Inherited folder permissions. Access granted on a parent folder flows down to the files and subfolders inside it.
5. Share links. If you opened a valid link, it contributes its role (up to Editor).

Because the highest applicable role wins, giving someone Editor on a folder and Viewer on one file inside it still leaves them an Editor on that file (via inheritance) — permissions never reduce access, they only add.

Granting access to users, groups, or the org

StretchDrive supports three kinds of recipients ("principals"):

1. User — one specific person.
2. Group — a team defined in your workspace; everyone in it gets the role.
3. Org — your entire organization.

To grant access:

1. Select the file or folder and open Share.
2. Choose the principal type (person, group, or organization) and the specific recipient.
3. Pick the role and confirm.

Guardrail: you can't grant a role higher than the one you hold on that resource. This prevents privilege escalation — an Editor can invite Viewers, Commenters, and Editors, but not Owners.

Removing access

Open the resource's permissions list and delete the entry you want to remove. Deleting a permission takes effect immediately. To manage a person's access to a whole area, manage it on the parent folder where it was granted rather than on each file.

A realistic example

Your finance team keeps everything under a Finance folder. You grant the Finance group the Editor role on that folder once. Every statement, export, and working file placed inside — today or next year — is automatically editable by the finance team through inheritance. When the external auditor arrives, you grant them a Viewer permission on just the 2026 Statements subfolder, so they can read and download those documents but nothing else and can't change anything. After the audit you delete that one permission and their access is gone.

Tips

• Grant at the folder level and let inheritance do the work — it's far less maintenance than per-file grants.
• Use groups rather than naming individuals so access follows team membership automatically.
• Reserve Owner for people who genuinely need to delete; most collaborators only need Editor.
• Give read-only stakeholders Viewer; use Commenter when they should be able to weigh in without editing.
• Audit sensitive folders periodically and remove stale grants.

FAQ

Can a Viewer see other people's shares? They can view the resource; managing who else has access requires Editor (share) rights.

Do workspace admins see everything? Owners and admins have Owner-level access across Drive by design, for governance and recovery.

If I lower someone from Editor to Viewer, is it instant? Yes, permission changes apply immediately on the next action.

Why did access I removed still appear to work? Check whether the person also has access inherited from a parent folder or via a share link — remove those too.