LEARN. PRACTICE. GROW.A verifiable access contract
Describe the contract before testing: which account, protocol, server, share, path, and operations are needed? A funds application might create a temporary file, write content, publish a final name, and expect another consumer to read the result. Successful listing covers only part of that journey. Prepare a matrix with operation, identity, expected outcome, and observed evidence. Add relevant negative tests, such as preventing writes where only reading should be allowed. TCP connectivity is an initial condition, not the conclusion. In this workshop exercise, the client pins and confirms SMB 2.0.2, uses a fictional account, and accesses only disposable loopback shares. Reporting identifies those conditions to make the conclusion auditable.
Observed authentication and negotiation
The first group starts an Impacket 0.13.1 server bound to 127.0.0.1 on an ephemeral port. An incorrect fictional password returns STATUS_LOGON_FAILURE; the credential defined for the laboratory is accepted. Two clients then use separate sessions with the observed dialect. There is no enterprise domain in this exercise. The distinction matters during investigation: valid authentication does not establish that the account represents the production user, Kerberos works, or an encryption policy was satisfied. Record the mechanism and properties actually assessed. For production entry, prepare tests with intended clients and identities and confirm security policy applicable to the real path.
Reading and writing are different decisions
In the second group, the RO share permits listing and reading reference.txt. Creating attempt.txt returns STATUS_ACCESS_DENIED and no file appears. This demonstrates the share read-only rule in that implementation without testing host ACLs. In a real service, effective identity, share configuration, and path permissions must be considered. Under NFS AUTH_SYS, matching client names can hide different numeric identifiers; root_squash can change the identity used by the server. Do not answer the first denial with broad privileges. Locate the responsible control, define the minimum required access, and repeat the functional operation with the intended account. Retain both allowed and denied outcomes in the acceptance record.
Execute the operation chain
The third group uploads draft.tmp containing BATCH-READY-17, reads it through the second client, renames it ready.dat, reads again, and removes the file. The old name becomes unavailable after the change. The sequence tests bytes and operations required by the small workflow, not processing of a financial instruction. It also neither cuts power nor proves crash durability. Use this distinction when building acceptance criteria: technical delivery can pass while the consumer still fails content validation. If a batch writes to a local folder because its expected mount is absent, success might not represent remote delivery either. Always confirm the actual destination.
Interpret the failure stage
The fourth group tries connecting to share ABSENT and reading absent.txt on a valid share. In this Impacket version, the first request returns 0xc000003a and the second 0xc000000f. The initial expectation for the share differed; reading smb2TreeConnect code confirmed the observation and allowed correcting the expectation. The lesson is to use relevant documentation and implementation instead of imposing a memorized code on every server. An error response also indicates that some component answered; it is not equivalent to a transport timeout. During an incident, combine stage, identity, target, operation, and response to involve the right team while preserving reproducible context.
Workshop: decide readiness
Prepare an acceptance table for an account that can read but cannot publish files. Explain to the sponsor which stage was validated, which was denied, and what evidence would permit proceeding. Include confidentiality as a separate requirement: SMB signing does not itself equal encryption. A parser such as testparm also does not execute the batch workflow. The local exercise provides evidence from seven SMB groups and one naming model but runs neither Samba, Windows, ONTAP, nor NFS. A facilitator can assess clarity, proportionality of correction, and retest criteria. The guide was authored for practice; no human session was performed. Summarize by connecting authorization, operation, and consumer outcome.
python3 -m venv /tmp/dr-nas-lab
/tmp/dr-nas-lab/bin/python -m pip install -r content/labs/nas-evidence/requirements.txt
/tmp/dr-nas-lab/bin/python content/labs/nas-evidence/run.py
# Only 127.0.0.1, temporary shares, fictional local credentials
# Recorded implementation: Impacket 0.13.1; negotiated SMB 2.0.2In a fictional funds service, share listing works but the batch account cannot create the file it must deliver.
Common pitfalls
Using ping as access proof, listing as write permission, administrator as the test account, and signing as encryption.
Related topics: Storage · Production Support L3 · Release Management
Accept the workflow the application needs to perform while keeping stages and evidence limits distinct.
Reference: Impacket 0.13.1 SMB server implementation · BigSavant NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior