Share permissions and network drives
See who can read or modify each share on your file servers, be warned when access opens up too widely, and declare your network drives for pre-diagnostics and the assistant.
A folder that "Everyone" can modify is ideal ground for ransomware. The Share permissions screen collects the permissions of your file server shares every day and works out what an ordinary user can do there.
Set it up
- Update the agent on your file servers to version 2026.10.11.3 or later (see Manage agents).
- In FSI Agents, open the gear button on the agent's card and turn on the Shares module. It is not on by default.
- The first collection arrives 5 minutes after you turn it on, then every 24 hours.
The agent reads the share permissions and the folder permissions, down to 2 levels below the root (at most 500 folders per share). Administrative shares (C$, ADMIN$, IPC$) and printers are skipped; SYSVOL and NETLOGON are kept. The agent changes no permission.
The effective permission
Access goes through two doors: the share permissions and the folder's NTFS permissions. The permission that counts is the lower of the two. So a share with full control for "Everyone" on an NTFS folder that is read-only gives read-only access.
FirstSI does this calculation for two populations:
| Population | Groups taken into account |
|---|---|
| All users | Everyone, Authenticated Users, Domain Users, Users |
| Guests and anonymous | Everyone, Anonymous, Guests, Domain Guests |
Groups are recognised by their security identifier, whatever the Windows language. An explicit deny is taken into account.
The tabs
Open File Monitor → Share permissions (#/partages).
| Tab | Content |
|---|---|
| Findings to review | The findings, filterable by status (open, accepted, resolved) and by server |
| Servers and shares | One card per server; a share's details show its permissions, the NTFS permission tree and the effective permission of each folder |
| History | Changes from one collection to the next (share added, permissions changed, inheritance broken, owner changed) over 30 to 400 days |
| Network drives | How your drive letters map to network paths |
In the tree, folders that only have inherited permissions are hidden; Show all … folders shows them all. After 48 hours, the collection is flagged "outdated collection".
The findings
| Rule | Label | Severity |
|---|---|---|
| PARTAGE-OUVERT | Overly broad access | high if the effective permission goes up to modify; medium for read access by Everyone or Anonymous |
| PARTAGE-CONTROLE-TOTAL | Full control for a broad group | high |
| PARTAGE-DROITS-MODIFIES | Permissions added for a broad group | high |
| PARTAGE-NOUVEAU | New share | medium |
| PARTAGE-HERITAGE | Inheritance broken | low |
A subfolder is only reported if it carries a permission for a broad group itself; an inherited permission is reported on the folder it comes from.
On the first collection, the risk findings are shown, and only Overly broad access and Full control for a broad group open an incident. The change rules start at the next collection.
Incidents are grouped: one per rule and per share. A finding resolves itself when the situation goes away, except New share, which stays open until it is accepted.
Accept a finding
Broad access can be intended (an exchange folder, a read-only software share).
- In Findings to review, open the finding.
- Enter the Reason for accepting (at least 3 characters), then confirm.
- The finding becomes Accepted. The share's incident closes when the last open finding for that rule has been dealt with.
An accepted finding only reopens if things get worse: higher severity, higher effective permission or a new broad group. Accepting is reserved for administrators and recorded in the audit log.
Network drives
In a ticket, people write "I can't get into G: any more" or "my folder in U:". The Network drives tab tells FirstSI what each letter stands for. Ticket pre-diagnostics and the AI Assistant use it to find the share and its permissions.
- In File Monitor → Share permissions, Network drives tab, click Add a drive.
- Letter: the letter followed by a colon, for example
G:. - UNC path: the share's path, for example
\\SRVFICHIERS\Commun. - If the path contains
{region}, choose the Region calculation. - Click Save. The whole list is replaced, and the change is recorded in the audit log.
Two variables describe a drive that differs from one person to the next:
| Variable | Replaced with |
|---|---|
{utilisateur} | the Windows logon of the person in the ticket, without the domain |
{region} | a part of the path specific to the person, according to the calculation chosen |
For example, \\SRVFICHIERS\{region}\users\{utilisateur} points to each person's home folder, sorted by region. The server name cannot contain a variable.
| Region calculation | What is used |
|---|---|
| Top-level organizational unit of the account (then collection) | the directory organizational unit just below the domain, read by the Directory module; failing that, the collection |
| Person's folder in the collection | the folder from the latest share collection that matches the pattern, for example Est\users\jdupont gives Est |
| Not calculated | nothing: the translation fails with "région inconnue" (unknown region) |
Calculating from the collection assumes that the Shares module runs on that server and goes deep enough to see the home folders.
As long as the list is empty, letters are not translated: pre-diagnostics ignores the drive quoted, and the assistant asks for the full path. Network drives are changed by an administrator; other users can view them.
Frequently asked questions
"No collection received yet". The Shares module is not enabled on the file server, or the agent is too old.
A home folder does not appear in the tree. The agent goes down 2 levels below the share's root. A deeper folder is not collected.
The drive "G" is refused. Enter the letter with its colon: G:.
Source: · FirstSI Docs · updated 2026-10-11