> ## Documentation Index > Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Analyzing File System Permissions > Who can access what in the file system, where a right comes from, and where inheritance is broken – evaluated from the last scan. *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](/docs/en/assets/lists). 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 | Tab | Question | | - | - | | *Overview* | How does it look overall? | | *Folder Analysis* | Who can do what on this folder? | | *Principal Analysis* | What can this user or group access? | | *Permission Origin* | Why can this principal do that on this folder? | *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: ``` Effective = NTFS ∩ SMB · Deny overrides Allow ``` *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: | Column | Full name | | - | - | | *Full* | *Full Control* | | *Mod.* | *Modify* | | *Read* | *Read* | | *Write* | *Write* | | *List* | *List* | | *Spec.* | *Special permissions* | 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. | Area | Finding | Severity | | - | - | - | | Directory service | *Non-local group directly authorized* | High | | Directory service | *User directly authorized* | High | | Directory service | *Orphaned SID* | Warning | | Directory service | *Empty group* | Warning | | Directory service | *Nested global groups* | Notice | | Shares | *Share within share* | High | | Shares | *Everyone with full access on share* | Warning | | Shares | *Access Based Enumeration deactivated* | Notice | | File system | *Everyone with Allow Permission* | Critical | | File system | *Everyone with Deny Permission* | Critical | | File system | *Full control for non-administrators* | High | | File system | *Deny Entry Present* | Warning | | File system | *Nested inheritance blocked* | Warning | | File system | *Special Permissions Set* | Warning | 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: | Number | What the subtitle actually counts | | - | - | | *Shares* | shares with at least one critical finding | | *Findings* | finding types with severity critical, not their occurrences | | *Broken Inheritance* | shares with the finding *Nested inheritance blocked* | 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](/docs/en/scan/ntfs-analysis). In this case the finding bar stays hidden entirely – its absence is not a clean bill of health for that principal. ## Related How the underlying analysis package comes into being is described in [Scanning NTFS Security](/docs/en/scan/ntfs-analysis). The second discipline in this area, known vulnerabilities, is covered by [CVE Analysis](/docs/en/analysis/cve). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.