Reviewed October 21, 2026. Commands are examples for an authorized, isolated lab; no target results are asserted here.
Listing share names and reading files are separate permission checks. A successful smbclient -L request does not prove that you can connect to every listed share, list its directories or open its files. When one operation works and another fails, identify the first failure before changing dialect or authentication settings.
Separate the four results
| Operation | Example result | Conclusion you can support |
|---|---|---|
| Enumerate share names | A table contains a share called training | The request returned that name; permissions remain untested. |
| Connect to training | The client reaches its interactive prompt without a tree-connect error | This session connected to that share. |
| List a directory | ls returns entries | The requested directory could be listed. |
| Read a selected file | A permitted file is retrieved | That file could be read; other objects and writes remain untested. |
These are illustrative outcomes, not results from a tested target. A server can expose share names while restricting connections, allow a connection while restricting directory listing, or allow listing without allowing file reads. A hidden or restricted share may also be absent from a particular enumeration response.
Make the two requests comparable
Use a verified target and the port already observed in scoped service discovery. Replace TARGET_IP, SMB_PORT, SHARE_NAME and the assigned-account placeholder. Do not substitute a server filesystem directory for its published share name.
# Request names
smbclient -L TARGET_IP -p SMB_PORT -U 'WORKGROUP/labuser'
# Connect to one known, permitted disk share
smbclient '//TARGET_IP/SHARE_NAME' -p SMB_PORT -U 'WORKGROUP/labuser'Let the client prompt for the password. Keep target, port, account and client configuration constant. Do not compare a blank-credential listing with a named-user connection and attribute the difference solely to the operation.
After the second command connects, issue ls at the interactive smbclient prompt, then quit. Record whether the failure happened before the prompt, during the initial directory listing or later inside a subdirectory. Quote names containing spaces using the syntax supported by your installed client.
If your exercise explicitly permits reading a selected sample file, use get for that file only and record its remote path and local destination. It copies remote data to the client. Do not recursively download the share or test write/delete operations merely because listing worked. Leave those permissions “Not checked.”
Use the stage and status together
| Where the failure appears | What to inspect next |
|---|---|
| Before SMB negotiation: timeout or refused connection | Address, current VM state, network and selected port |
| Protocol negotiation | Actual negotiation evidence and installed client policy |
| Session setup: for example LOGON_FAILURE | Assigned account format, credential validity and authentication policy |
| Tree connect: BAD_NETWORK_NAME | Exact published share name and whether it exists in that server context |
| Tree connect: ACCESS_DENIED | Share connection policy, effective identity, permissions and applicable protection requirements |
| Directory or file request: ACCESS_DENIED | That object’s list/read/traverse rights and server-side policy |
A status code alone is not a complete diagnosis. Windows share/NTFS permissions and Samba share rules/filesystem permissions can both affect access. A parent directory’s traversal rights can matter even when the final file’s mode appears permissive. Server logs and configuration may be needed; inspect them only when the lab grants administrator access.
IPC$ and printer shares are not ordinary disk shares. Do not treat the absence of a file listing on such a service as proof that every share is broken. Likewise, a warning during a later workgroup-browsing step is a separate event from an earlier successful share enumeration.
When should dialect settings change?
Only when the failed stage and other evidence justify a specific compatibility test. A directory denial after a successful session does not by itself establish an SMB1 requirement. Use the scoped legacy negotiation guide for a confirmed legacy-only lab. -m NT1 controls the maximum and cannot by itself lower an incompatible minimum. Keep security policy changes out of a permissions experiment.
Write a result another learner can reproduce
Illustrative note: “Share enumeration returned training for the assigned account. A separate connection to training succeeded using the same target and port. Listing its root directory returned ACCESS_DENIED. File reads and writes were not tested.” Attach the real commands, timestamps and error lines before treating this as your finding.
Use the SMB operation record to keep each result separate. If the share connection itself failed, continue with tree-connect troubleshooting. If only the exact software build is missing, see what Samba version clues actually prove.
Primary references: Samba smbclient manual and Microsoft’s SMB failure-stage troubleshooting.