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 its detail page, which opens from the Name column. Search, filter and sort work like in any other list, see Lists and Filters.
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.

​
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 of the thirteen 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.
The five groups follow different rules: an allow marks the column only when every individual right in the group is present; a deny already marks it once a single one is denied. The reason lies in Windows itself, which often records only individual rights on a deny – a partial deny still removes the full right.
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. Which row it actually concerns only the detail panel reveals.
A question mark in all five permission columns of a folder row in Principal Analysis means the entry carries special permissions that cannot be mapped onto these five groups. 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.
Both inputs are frequently already set before the tab is even opened: the arrow at the end of a row, in either Folder Analysis or Principal Analysis, opens Permission Origin directly and carries the principal and folder along.
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 standing total down to that point. A run of unchanged levels is collapsed into a single row so that a deep path stays readable.
Cumulative only sums the NTFS rights down to that station – 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 states where a right is set, the chain states through what the principal is tied to 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. The actual boundary is drawn one level down, in the file system, where the same entry is critical.
A finding text without a count in parentheses does not mean it occurs only once – the interface simply did not supply a count 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, Broken Inheritance. 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. The shares below are sorted by state, Critical first and shares without a finding last; clicking one jumps to Folder Analysis with that share preselected. Below that, Top Findings lists the findings across the whole analysis, sorted by severity first and by count on a tie. With no finding at all, this section is left out entirely.
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, no orphaned entry exists in this analysis at all – an empty category is not shown.
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.