IT & infrastructure
Shares: who can open what, and since when
A directory does one thing daily: decide who opens which folder. Groups, inheritance, and the tree you should stop copying from the org chart.
The companion article says, in its section 5, that the directory is what you are really buying with a server. That is correct, and it then moves on.
What a directory is for day to day, in a business of this size, fits in one sentence: deciding who can open which folder. It is the only real use we see, and it is the one that is almost never maintained.
The symptom is not a leak. It is twofold and more ordinary: nobody can find anything, and everybody can open everything. Both come from the same decision, taken once and never revisited.
This page is about rights rather than servers. It applies just as well to a shared storage box or an online folder, and the only thing that changes from one tool to another is the names of the buttons.
Two symptoms, one cause
The first symptom is the one everybody complains about: nobody can find anything. The file exists, somebody filed it somewhere, and the search takes ten minutes three times a day.
The second is the one nobody mentions: everybody can open everything. The accounts folder, the payroll folder, the contracts folder are reachable from any workstation by anybody.
Both come out of the same decision, taken once and never reviewed: at installation, somebody created a tree and gave access to everybody, because that was the only way to make the whole thing work that day.
We stress this because it sets the tone for everything else: it was not a mistake. Restricting rights on day one of an installation, before anybody knows who works on what, produces a blocked business and twenty phone calls the next morning.
What never happened is the second pass. Six months later, when it is clear who does what, nobody goes back to that provisional decision — which is exactly the mechanism the firewall-rules article describes for a different object.
What a right means, in three words
Three minutes of vocabulary are needed before anything can be decided, and these three words are enough for a business of this size.
Read means open and copy. It is the most underestimated right: somebody who can read can take away, and most of the situations that genuinely worry an owner are readings rather than modifications.
Write means modify and create. It is the one everybody grants by default because it is the only one that allows work, and it is also the one that produces overwritten files.
Delete nearly always comes bundled with write, and it is the only one of the three whose effect is not immediately visible. A folder several people can delete in is a folder where a file disappears one day with nobody remembering having touched it.
The working rule that follows from these three words is simple and settles half the cases: most people need to write in two or three folders and read in five or six. Nobody, in a ten-person business, needs to write everywhere.
Rights go to groups, never to people
This is the page’s central rule and it decides whether the arrangement holds for two years or two months.
A right attached to a person has to be re-decided at every arrival, every departure and every change of job. A right attached to a role — accounts, sales, workshop — is decided once, and somebody arriving means putting them in the right group.
The difference is not elegance, it is workload, and that is what makes it decisive: the per-person version demands a competent decision at every movement, and a ten-person business has about ten movements a year.
Four or five groups nearly always suffice, and the temptation to make twelve has to be resisted. One group per department, one for management, and an "everybody" group that exists anyway. Beyond that, the per-person problem returns under another name.
The particular case that always comes up: the person belonging to two departments. They go in two groups, and that is all — which is precisely what groups do well and what a tree copied from the org chart cannot do at all.
The "Accounts" folder open to everyone
The concrete case is worth handling rather than the principle, because it is what we find in the great majority of installations and it has a ten-minute solution.
The folder exists, it is correctly named, and its access was never restricted. Three or four folders are in that state in an ordinary business: accounts, payroll, contracts, and often a "management" folder created one day and never protected.
The correction is not to close everything. It is to decide, for those three or four folders only, which group can read and which can write, and to leave the rest of the tree exactly as it is.
It is the only intervention on this page that produces an immediate effect with no risk, which is why it comes before the reorganisation in section 8. Restricting three sensitive folders breaks nobody’s work; reorganising a tree always breaks a little.
One precaution that avoids the classic incident: tell people before restricting, and keep a day free for the calls. There is always somebody you did not know needed that folder, and it is nearly always somebody whose real work does not match their job title.
Inheritance, and the folder that is not what it looks like
Here is the only technically difficult part of this page, and it explains why a folder that looks correct is not.
Rights flow downward. A folder inherits what was decided above it, which is very convenient — decide once at the top of a branch and everything below follows — and which produces two regular surprises.
The first: a subfolder created in an open area is open, even if its name suggests otherwise. A "Payroll 2026" folder created inside "Human Resources", which is itself inside "Shared", is readable by everybody, and its name changes nothing.
The second: a moved file sometimes keeps the rights of its old location, whereas a copied file takes those of the new one. It is the commonest cause of a sensitive file being readable inside a properly protected area, and it is invisible until looked for.
The practical rule that avoids having to understand the detail: decide rights **high** in the tree, on four or five top-level folders, and do not re-decide them below. A tree whose rights are adjusted in ten different places is a tree nobody can explain any more, including the person who built it.
The overwritten file, and five versions of one document
Sharing produces a problem that access rights do not solve and that has to be handled separately, because it is the one people complain about most.
Two people open the same document, the second saves after the first, and the first person’s work disappears with no message. On a classic file share this happens silently and there is nothing to configure to prevent it.
The natural reaction creates the second problem: everybody saves their own copy under a new name. Six months later the folder holds "Client quote final", "Client quote final 2", "Client quote final OK" and "Client quote final real", and nobody knows which one was sent.
Two answers exist and the choice should be made knowingly. The first is a convention: a file belongs to one person while they are working on it, and that is said out loud in a team of five. The second is a tool that handles simultaneous editing, which means an online folder rather than a classic share.
We do not settle it here, because the choice depends on the connection and on offline work, and the hosting article covers what the second costs. What we do say is that the problem is not a rights problem, and that adding restrictions does not fix it — it makes it worse, because people work around it on their desktops.
The personal folder, and why it is not private
Everybody has a folder in their name, and that obvious arrangement carries two misunderstandings better cleared up in advance than during a dispute.
The first is on the company’s side: that folder is not a backup. Work filed there is protected like the rest of the server and no more, which is fine, and it is no more recoverable than anything else if nobody has restored it.
The second is on the person’s side: that folder is not private. It is on company equipment, the administrator technically has access, and that has to be said once, clearly, on arrival. A business that lets people believe otherwise creates the worst possible moment on the day it has to open that folder.
What is legitimate and is said in one sentence: the personal folder is for work in progress, it is not monitored, and it can be opened by the business if necessary — on a departure, a long absence, or an operational need.
The most useful practical consequence is not legal: it is that finished work must not stay in a personal folder. An approved quotation, a signed contract, a site photograph live in the department folder, and that is what stops a departure becoming a search.
The tree copied from the org chart
This is the commonest design error and it produces the first symptom from section 1: nobody can find anything.
In nearly every installation we open, the top level is a list of departments: Sales, Accounts, Technical, Management. It is the obvious division, it looks like the org chart, and it does not match how work actually flows.
The proof is immediate and you can run it this morning: take a real client file and ask where its pieces are. The quotation is in Sales, the invoice in Accounts, the photographs in Technical, and the signed contract in Management. Four places for one piece of business, and nobody can reconstruct it without touring all four.
The division that works follows **what people work on** rather than the department they belong to: by client, by site, by job, by year depending on the trade. Rights stay by group — which is precisely what groups make possible, since a job folder can be open to three departments without being open to everybody.
We do not recommend reorganising everything at once. The rule that works is to leave the old tree readable and create the new one for current business from a given date. After a year the old one is an archive nobody opens, and nothing was migrated.
Departure, and the rights that stay behind
A departure is handled in two minutes or in three weeks, depending on what was done in sections 3 and 7.
If rights are attached to groups, the departure is removing the person from their groups and disabling their account. Two minutes, and access stops everywhere at once.
If rights were attached to people, the tree has to be reviewed looking for their name, and nobody ever does that completely. That is how you find, two years later, a disabled account still listed in the rights of fourteen folders — harmless until the day it is re-enabled for some reason.
The account is disabled rather than deleted, for the same reason as in the badge article: deletion loses the link between files created and the person who created them, and that information is useful more often than people expect.
And what has to happen the same day, before anything else: the contents of section 7’s personal folder are moved into the department folder. It is a ten-minute operation that never happens again once the person has gone and the account is closed.
The annual review, in one hour
Like the firewall and like the badges, a set of rights is reread once a year. The method is shorter here because the structure is smaller.
Two lists suffice, and they get printed. The first: the four or five top-level folders, with the group that can read and the group that can write. The second: the members of each group.
Reading it means asking one question per line of the second list, and it is the same as in the firewall article: does this person still work here, and are they still in this department? Two answers, three seconds each, for twelve people.
What appears every time is of three kinds. Accounts of people who left, still sitting in a group. People who changed department and are in both. And at least one top-level folder created during the year whose rights nobody decided.
Note the date on the sheet and keep it. Next year’s review starts by comparing, which takes ten minutes — the same mechanism as everywhere else in this pillar, and worth as much here.
What this page cannot put a number on
We will give no figures about access rights, and the reason differs from the ones given elsewhere in this pillar.
Elsewhere the figure exists and is badly measured, or is measured by an interested party, or is destroyed before being recorded. Here there is nothing to measure: a business does not have "too many" or "too few" rights, it has a structure.
A business with four departments and a two-partner business with a shared drive do not have different quantities of the same thing. They have incomparable objects, and an average between them would describe a business that does not exist.
That is why this page contains no numeric benchmark and a lot of shape rules. "Four or five groups", "three or four sensitive folders", "decide high": those are orders of magnitude for a ten-person business, not measurements.
The only figure worth anything is section 10’s, and it is entirely yours: the number of lines the annual review makes you correct. If it grows year on year the structure is not holding; if it shrinks, it is.
What we do, and what we refuse to do
What we refuse first: restricting rights on installation day, before anybody knows who works on what. That produces a blocked business and twenty calls the next morning, and it would earn us a second billed day to reopen everything.
We also refuse to reorganise an entire tree over a weekend. It is the most saleable project on this page and the one that fails most often: people keep going where they always went, and you end up with two trees instead of one. Section 8’s rule — the old one readable, the new one from a date — is slower and it holds.
And we refuse to set up per-person rights, even when the client asks for it because it is quicker to explain. It works for the first month and becomes unmanageable at the third staff movement, which is to say within the year.
What we do fits in half a day: the three or four sensitive folders restricted, four or five groups created and populated, rights decided high in the tree, and section 10’s two lists printed and dated.
And one thing to do today without us, in five minutes: ask somebody on the shop floor to open the payroll folder from their workstation. If they can, you know this page’s first job, and it is corrected in ten minutes.
Frequently asked questions
Why can everybody open the accounts folder?
Because access was opened to everybody on installation day, which was the right decision that day — restricting before anybody knows who works on what blocks the business — and because the second pass six months later never happened. The correction is not to close everything: decide rights for three or four sensitive folders only and leave the rest as it is.
Should rights go to people or to groups?
To groups, always, and the reason is workload rather than elegance. A right attached to a person has to be re-decided at every arrival, departure and change of job — about ten times a year in a ten-person business. Four or five groups suffice, and somebody in two departments simply goes in two groups.
Is a well-named subfolder protected?
No. Rights flow downward: a "Payroll 2026" folder created inside an open area is readable by everybody, and its name changes nothing. Second trap, invisible until looked for: a moved file sometimes keeps the rights of its old location, whereas a copied file takes those of the new one.
How should the tree be organised?
By what people work on — client, site, job — rather than by department. The proof takes a minute: take a client file and look for its pieces. Quotation in Sales, invoice in Accounts, photographs in Technical, contract in Management: four places for one piece of business. Do not migrate; leave the old tree readable and create the new one from a date.
Is an employee’s personal folder private?
No, and that is said once on arrival rather than during a dispute: it sits on company equipment and the administrator technically has access. It is not monitored and it can be opened if necessary. The useful consequence is elsewhere: finished work — an approved quotation, a signed contract — lives in the department folder, and that is what stops a departure becoming a search.
What happens to rights when somebody leaves?
If rights are by group: remove the person from their groups and disable the account, two minutes, and access stops everywhere at once. Disable rather than delete, to keep the link between files and their author. And move the contents of their personal folder into the department folder the same day — that is the operation that never happens once the account is closed.
Where we come in
The payroll folder either opens from any desk or it does not. What that test cannot say is what would break if you closed it.
- We close the handful of directories that matter, never the whole tree.
- We create four or five groups, never permissions granted person by person.
- We wait until we know who works with what before closing any door.
If nobody at your company can say who uses which folder, touch nothing yet: a restriction set blind stops the work on Monday morning.
Read next
Windows Server: what you actually buy when you buy a server
The machine is bought once, the right to use it is paid per person. And it carries a written end date, which is the only certain one in this pillar.Replacing a system that still works
Four reasons justify replacing an old application. Outside those four, keeping it is almost always the right call — and nobody has an interest in telling you so.Running a model on your own machine: the three numbers that decide
The number in a model’s name does not say whether it will fit. Three others do, and they are worked out before buying anything.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.