A VDI data-drive root can create folders but not files: how to repair the ACL consistently
Review advanced root permissions, OI/CI inheritance, user SIDs, persistent disks, and the master image, then repair through a pilot and controlled script or GPO rollout.
Review advanced root permissions, OI/CI inheritance, user SIDs, persistent disks, and the master image, then repair through a pilot and controlled script or GPO rollout. For this case, first verify D: root ACL and OI/CI inheritance flags, then use user SID and ownership to decide whether remediation is needed.
Define the failure boundary first
For this virtualization and VDI case, establish the failure boundary with D ACL and OI/CI inheritance flags, then continue to SID. Capture the current state, incident time and one known-good comparison before changing production configuration.
Work through the dependency chain
| Check | Why it matters | Recommended action |
|---|---|---|
| 01 · D: root ACL | Verify D: root ACL on the affected path using logs, counters or state information rather than relying only on the configured rule. | Record the current value, evidence source and timestamp for D: root ACL. If adjustment is required, change one condition only and retain the original setting for rollback. |
| 02 · OI/CI inheritance flags | Verify OI/CI inheritance flags on the affected path using logs, counters or state information rather than relying only on the configured rule. | Check OI/CI inheritance flags read-only and save the result. If it differs from the baseline, correlate it with the incident time and recent changes before remediation. |
| 03 · user SID and ownership | Verify user SID and ownership on the affected path using logs, counters or state information rather than relying only on the configured rule. | Compare user SID and ownership with a known-good peer, the log timeline and the real application path; confirm whether it is causal before changing production. |
| 04 · persistent-disk mounting method | Review the current state, related logs and recent changes for persistent-disk mounting method, then align them with the incident timeline before deciding whether a change is required. | Record the current value, evidence source and timestamp for persistent-disk mounting method. If adjustment is required, change one condition only and retain the original setting for rollback. |
| 05 · golden-image and clone strategy | Review the current state, related logs and recent changes for golden-image and clone strategy, then align them with the incident timeline before deciding whether a change is required. | Check golden-image and clone strategy read-only and save the result. If it differs from the baseline, correlate it with the incident time and recent changes before remediation. |
| 06 · pilot script and rollback | Review the current state, related logs and recent changes for pilot script and rollback, then align them with the incident timeline before deciding whether a change is required. | Compare pilot script and rollback with a known-good peer, the log timeline and the real application path; confirm whether it is causal before changing production. |
Change only after the evidence is clear
- Start with read-only evidence. Check D: root ACL and OI/CI inheritance flags before changing configuration.
- If the first checks are normal, continue with user SID and ownership and persistent-disk mounting method, keeping evidence tied to the incident time.
- Change configuration only when the evidence explains the symptom. For golden-image and clone strategy, preserve the original value and define the rollback trigger before adjustment.
- Validate pilot script and rollback in a controlled scope before expanding to production users or traffic.
Validation and rollback
- Validate the complete user or application workflow; do not stop at the single status of D: root ACL.
- Recheck golden-image and clone strategy and pilot script and rollback after the change and confirm that no new bypass, permission expansion or secondary error has appeared.
- Archive evidence from D: root ACL through pilot script and rollback, together with before/after configuration, business validation and the rollback point.
Common wrong turns
- Changing D ACL and OI/CI inheritance flags at the same time, which makes the original cause impossible to prove.
- Treating a normal result for SID as proof that persistent-disk mounting method and the rest of the business path are healthy.
- Leaving a temporary exception related to golden-image and clone strategy or pilot script and rollback in production without an owner, expiry time and rollback note.
Related questions
Where should I start with “A VDI data-drive root can create folders but not files: how to repair the ACL consistently”?
Start with D: root ACL and OI/CI inheritance flags; they establish the first useful troubleshooting boundary without changing production state.
What should be checked after the first layer looks normal?
Continue with user SID and ownership and persistent-disk mounting method, then correlate the result with the incident time and the actual user or application path.
What should be retained after the change?
Keep evidence for golden-image and clone strategy and pilot script and rollback, plus the original configuration, validation result, observation notes and rollback point.