LEARN. PRACTICE. GROW.Prepare and predict the results
The exercise uses a disposable Linux VM with a memory-backed root, two local identities and shares created by the script. There is no enterprise domain. Before running it, build a grid containing account, share, operation, expected result and required evidence. Include an incorrect-password attempt, authorized reading and denied writing. The report lets you compare that prediction with actual SMB requests. Laboratory accounts and passwords are public and synthetic; they are not a model for managing real secrets. The script checks its environment before creating resources and records cleanup. If those conditions do not match, investigate preparation instead of removing the checks to force execution.
Read a denial in its context
In the first comparison, testparm accepts the configuration, but a connection with an incorrect password returns NT_STATUS_LOGON_FAILURE. These checks concern different stages. Next, the correct account reads a reference and receives NT_STATUS_ACCESS_DENIED when attempting to write to the read-only share. The underlying directory permits group writing, so that permission alone does not explain the share denial. In the fictional ticket, record the command without secrets, synthetic identity, time and operation. Do not group every result as a network failure. The analysis aims to formulate a specific, testable hypothesis while distinguishing rejected credentials from an operation denied after authentication.
Compare accounts on the same share
The next share points to the same directory but grants a write exception to drnaswriter. That account uploads the file and the report compares the new object UID with the expected UID. The drnasreader account remains unable to upload another file despite belonging to the same local group. This creates a useful negative check: demonstrating producer success alone does not show that restrictions on other users remain intact. A third share places the same account in both allow and deny lists; the connection is rejected. Discuss each outcome alongside the complete configuration, without assigning unproven capabilities to the share name or the visual order of configuration lines.
Follow the path to the object
The final two denials in this lesson arise from host conditions. A directory in mode 0555 does not permit the observed creation even through a share configured for writing. On another path, the final folder is 0777, but a 0700 ancestor belongs to root. The client identity does not gain access merely because the final folder looks permissive. In a fictional migration incident, compare the complete path and effective identity before and after the change. Propose the smallest correction consistent with approved policy, identify its owner and repeat allowed and prohibited operations. The final grid should explain what changed, which hypothesis was confirmed and which enterprise checks remain outstanding.
# INSIDE the prepared disposable guest only.
# Preparation: content/labs/nas-samba/README.txt
python3 /mnt/dr/run.py --output /mnt/dr/evidence.json
# Public synthetic identities; Samba 4.23.8; loopback port 1445.
# This lab creates and removes its own local users and shares.A batch account can read the reference file, but only the account authorized in write list can upload the new file.
Common pitfalls
Confusing parsing with acceptance, replacing the batch account with an administrator or changing a folder without examining its ancestors.
Related topics: L3 and RUN handover · NAS identities and permissions
An authenticated session does not grant every operation. Explain the observed control and demonstrate allowed and denied permissions.
Reference: Samba share access and creation permissions · BigSavant NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior