starfyrepo
← Journal Access Permissions

Access Permissions: Common Mistakes on Shared Drives and How to Avoid Them

Most permission problems on shared video drives come from a few repeated habits. Marcus Delgado walks through the common ones and shows how a simple permissions matrix prevents them.

Marcus Delgado · · 6 minutes to read

Access Permissions: Common Mistakes on Shared Drives and How to Avoid Them

Giving everyone edit rights because it is easier

The most common mistake I see on production drives is also the most understandable one. A project starts quickly, the team is small, and someone sets the whole shared folder to full edit access so nobody gets blocked. It works for the first week. Then a freelancer drags a folder into the wrong place, an assistant renames a camera original, or a cleanup of the drive removes a sequence nobody realised was still in use.

The problem is not carelessness. It is that edit rights on everything mean any mistake can reach anything. Footage that was ingested once and should never change sits right next to working project files that change every hour. They need different rules, and a single blanket setting cannot give you that.

The fix starts with sorting, not software. List the kinds of material on the drive: camera originals, working project files, exports for review, final deliverables. Then decide for each kind who may read it, who may change it and who may delete it.

  • Camera originals: read-only after ingest for almost everyone
  • Project files: edit rights limited to the people cutting
  • Review exports: read access for clients and producers
  • Final deliverables: locked once approved

Never writing the rules down

A permissions setup that lives only in the head of whoever built it will fail the moment that person is on leave or leaves the company. I have seen teams spend an afternoon guessing why a new editor could not open a folder, when the answer was a setting someone applied two years earlier for a reason nobody remembered.

A permissions matrix solves this and fits on one page. Rows are roles, columns are the folder areas, and each cell says read, edit, approve or no access. It takes an hour to draft and saves far more than that in questions over a year.

Keep it next to the folder structure documentation, not buried in an email. When the matrix and the real drive disagree, one of them is wrong, and having the document is what lets you notice. Review it whenever someone joins, changes role or leaves a project, and note the date of each change in the file itself.

Confusing who can edit with who can approve

Many teams treat approval as a social event rather than a permission. A producer says in a chat that a cut is approved, and the editor exports it. Weeks later, nobody can say which export was the approved one, or who agreed to it. Approval has quietly become a rumour.

Separate the two ideas on purpose. Editing is the right to change a file. Approving is the right to declare a specific version final and to move it into the delivery area. Often these belong to different people, and the person who can approve should not need to be able to alter the cut.

In practice this can be as simple as one folder, such as an approved-exports area, where only two named people can add files. Everything else is read-only. When a client asks which version was signed off, the answer is whatever sits in that folder, and the folder history shows when it arrived.

Forgetting people who come and go

Freelancers, interns and outside colourists tend to be added in a hurry and removed never. Months after a project wraps, the access list still includes people who have no reason to see the material, sometimes including unreleased footage. This is a privacy and contract risk, and it also makes the list harder to read for everyone.

Treat access like a loan with an end date. When you add someone for a job, note the folders they can reach and the day the work is expected to finish. At wrap, remove them as part of the same checklist you use to close the project.

Where the storage allows it, use groups rather than individual grants. Adding a person to the colour group or the offline editor group is quick, and removing them is just as quick. Individual exceptions pile up, and every exception is something a future administrator has to decode without any context.

  • Give each outside collaborator an end date when access starts
  • Use role groups instead of one-off personal grants
  • Remove access as a fixed step of project wrap

Changing permissions without testing the result

A well meant tidy-up can lock the whole team out of a folder, or worse, open one that should have stayed private. Permissions on shared drives and cloud storage often inherit from parent folders, so a change high in the tree spreads downward in ways that are easy to miss.

Before applying a new setup to a live project, try it on a small test folder with a test account for each role. Log in as the assistant and confirm they can read the originals but not delete them. Log in as the producer and confirm they can reach the review area. This takes minutes.

Make changes in the quiet part of the week, tell the team beforehand, and keep a note of the previous settings so you can step back. If something breaks, you want to know exactly what changed and when, rather than reconstructing it from memory under deadline pressure.

Treating permissions as a one-time job

The last mistake is assuming that once the matrix exists, the work is finished. Teams change, projects move from shoot to edit to delivery, and the right access at each stage is different. A drive that was sensible in the first month can be wrong by the fourth.

Build a short review into the rhythm of the project. At the end of each phase, open the matrix and ask three questions: who no longer needs access, who now needs more, and does anything on the drive sit in the wrong area. Fifteen minutes is usually enough.

These weeks of autumn are a natural point for it, as many teams are between jobs and tidying up before a busy stretch. Reviewing now means the next project starts on a clean footing instead of inheriting every shortcut from the last one.

Permission problems rarely come from one big error. They build up from small shortcuts: blanket edit rights, unwritten rules, informal approvals, forgotten guests and untested changes. A one-page matrix, a clear split between editing and approving, end dates for outside people and a short review at each phase will prevent most of them. Start with the matrix, since everything else depends on it, and keep it beside your folder structure so both stay honest.

Send us a message

418 Central Avenue NW, Albuquerque 87102(505) 214-0873[email protected]

© 2026 starfyrepo. All rights reserved.