Skip to main content
File System—the only menu entry under the group heading Permission Analysis—reads the results of the NTFS Security scan module: who can access which folders and shares, where a right comes from, and where inheritance is broken. No field or button in this area sets or removes a permission—what you see is exclusively the state of the last scan, carried in the column Last Scan. Fix a deviation you find on the affected system itself; only a new scan brings the updated state back into Docusnap365.

​
Rows of the list

Each row of the list under File System is one analysis with Name, Analysis Package, Type and Domain. The individual shares only appear on the detail page of the analysis. Search, filter and sort work like in any other list, see Lists and Filters. You delete analyses from the list by selecting rows, or one at a time from the header of an open analysis. Both require the delete permission in the Analysis area; without it, the list offers no selection and the header has no Delete button. In the list, Delete handles at most 1000 individually selected analyses; selecting all rows at once disables the button.
The header of an open analysis repeats this timestamp in its subtitle—but only once the Overview tab has been opened at least once. Until then the subtitle stays blank; the timestamp can still be read from the list.

​
Tabs of an analysis

Overview and Folder Analysis summarize the existing data, Principal Analysis looks at it from the opposite direction, and Permission Origin resolves one specific case.

​
Effective permission

A right only takes effect once both sides grant it: the file system itself (NTFS) and the share it is reached through (SMB). The Permission Origin tab states the rule under its result table:
Full Control in the file system with only Read through the share leaves just Read in effect—the most common reason someone “can’t write despite having permission.” Folder Analysis lists NTFS and SMB entries side by side in one table without combining them; only Permission Origin does that.
A deny on either side alone is enough to remove a right. The table cells know three states: a checkmark for allowed, a cross for denied, a gray dot for not set.
Permission Origin adds a fourth symbol: a question mark that shows Special Permissions on hover. It appears in every unset cell of a row that carries rights outside the five groups—for example, a row whose only right is Create Folders / Append Data. A row with question marks carries rights even when no column is set. This applies to the result table, the entries of each station and the Cumulative row.

​
Reading the permission columns

Both permission tables carry five abbreviated columns, and Folder Analysis adds a sixth. Hovering over a column header reveals the full name: These five are the groups Windows bundles the individual rights into. An entry that cannot be mapped fully to any of them is marked in Spec.; which individual rights actually apply then shows only in the row’s detail panel.
Read and List differ in exactly one case: an entry carrying only the right Traverse Folder / Execute File shows a checkmark in List and nothing in Read, because that one right belongs to the List group, not to Read. In every other case the two columns match.
A column is marked only when every individual right in its group is present—for an allow and a deny alike, matching the Windows security dialog. A deny on individual rights that does not cover a whole group marks none of the five columns. The row’s detail panel shows which individual rights are denied: there each right carries its own state—allowed, denied or not set.
The Spec. marking applies to the whole folder, not to the individual row: if even one entry in it carries special permissions, the column is marked in every row of that folder—including rows without such rights. Only the detail panel shows which row it concerns.
If a folder row in Principal Analysis carries rights that none of the five groups fully covers, its empty permission columns show a question mark; columns whose group is fully present keep their checkmark. The individual rights show in the detail panel of the matching row in Folder Analysis.

​
Inventory and explanation

While Folder Analysis and Principal Analysis each take stock from their own side, Permission Origin resolves one specific case—for that it requires two inputs: a principal and a folder.
Missing either input leaves the area empty, with the message “No folder data available for this principal.”—even when the principal is already chosen and only the folder is missing.
The arrow at the end of a row, in either Folder Analysis or Principal Analysis, opens Permission Origin with the row’s principal and folder already set.
A single user or a global group with direct access to a folder counts as more conspicuous than a domain-local group: such a name stands out in the header of Principal Analysis, the same way Everyone and orphaned entries do.

​
Structure of the permission origin

NTFS Origin draws a path below the result table, from the chosen folder down to the share root: one station per level, each with its own permission entries and a Cumulative row for the NTFS rights that apply there. A run of unchanged levels is collapsed into a single row so that a deep path stays readable.
Cumulative shows what applies in the file system at that station, including rights inherited from the parent folder—even at a station whose only entry is a deny. It is not yet the effective right. Share entries at a station appear in their own Share (SMB) block and are not part of that sum, because they only cap access on top of it. The combined result of both sides is stated solely by the Effective row in the table above.
When a right comes through a group membership rather than directly, expand the station: Membership then shows the path from the principal to the authorized group. The station names where the right is set; Membership names the groups through which the principal receives it.
The same derivation is also drawn as a graph by the Permission Origin button above the result table; the group structure around a single principal opens instead through User & Group Structure in the header of Principal Analysis. With either the principal or the folder missing, Permission Origin stays disabled.

​
Findings and their classification

Fourteen finding types fall into four levels—Critical, High, Warning, Notice. Where several meet on the same share, folder or principal, only the most severe counts; a share without any finding carries no marking at all.
The only findings classed critical are the two Everyone entries in the file system, regardless of direction. What is judged is the use of Everyone itself, not the effect of the individual entry: Microsoft advises against using Everyone in file system permissions at all—a deny on it shows the same unclean structure as an allow.
At share level this assessment reverses: Everyone with Full Access on Share only counts as a warning, because the share level does not restrict anything by itself. Access is restricted one level down, in the file system, where the same entry is critical.
A finding text without a count in parentheses can occur more than once; no count is available for that entry.
The colored dot behind a folder in the tree does not come from the findings. It follows three other properties of the node—missing data, broken inheritance, direct rights—with missing data always taking priority. A folder can look unremarkable in the tree while its own finding bar shows a warning; the finding bar is what counts.
The badge in the folder header distinguishes two cases: Broken marks a folder below the share whose inheritance is broken; Explicitly Set marks a folder with direct rights while its inheritance is intact. For a single row, the detail panel shows Active or Broken under Inheritance. A share permission (SMB) has no NTFS inheritance, so this value is absent for it.

​
Numbers in the Overview tab

Five values sit side by side in the Overview tab: Shares, Folders, Principals, Findings, Inheritance Breaks. For three of them the subtitle underneath does not count the same thing as the headline value: Two critical finding types with twenty occurrences each, for example, read as “2 critical findings”—not forty. Clicking one of the shares below jumps to Folder Analysis with that share preselected. Below that, Top Findings lists the findings across the whole analysis.
Clicking an entry in Top Findings opens Folder Analysis or Principal Analysis but preselects nothing there. The folder or principal itself still has to be located in the target tab.

​
Quirks of the principal analysis

The search field of the principal list does not filter it, it extends it: only principals already present in this analysis are shown at first. A principal found through search is added to the list and marked Added—conversely, a principal absent from the list does not automatically mean it has no rights, only that it does not appear until you search for it.
If the heading Orphaned is missing, the analysis contains no orphaned entry; an empty category is not shown. The count next to each right in the filter bar includes folders inside collapsed subfolders. With a filter active, the folder table shows every match; folders on the way there that do not match themselves appear dimmed in between.
Narrowing the filter bar to a single right does not remove shares where the principal lacks that right; they stay visible, only dimmed. That keeps it visible that the share exists and that this particular right is missing there.
If a share carries a right denied at share level, its header shows Denied: followed by the name of the right. This deny overrides every allow.

​
Timeout during the calculation

With very deep folder structures, the calculation for a principal can exceed the time limit; instead of results, a message with a recommendation then appears. It points at the scan job: the NTFS Security job lets you configure a maximum folder depth, see Scanning NTFS Security.
In this case the finding bar stays hidden entirely—its absence is not a clean bill of health for that principal.
How the underlying analysis package comes into being is described in Scanning NTFS Security. The second discipline in this area, known vulnerabilities, is covered by CVE Analysis.