Gary VirkIT Specialist
← All work

07 IT support · SMB · Samba

SMB authentication and share permissions

An isolated Samba lab shows the difference between a wrong password and a valid user who lacks access to the share.

Issue
The share is reachable, but access fails. Did authentication fail, or did a valid user reach a share they were not authorized to open?
Decisive evidence
The lab produced distinct logon-failure and access-denied results for the same reachable SMB service.E01
Result
Two users can reach the same SMB service and fail for different reasons, so connectivity, authentication, and authorization must be checked separately.
Boundary
This is one Samba server and a synthetic read-only share.Full limit
Completion
Complete within stated scope
Execution
Isolated Samba client and server run
Review
Scripted assertions and artifact check
Evidence
Selected evidence on this page
  • Samba 4.21
  • SMB client
  • Docker internal network
  • ARM64

The support question

The share is reachable, but access fails. Did authentication fail, or did a valid user reach a share they were not authorized to open?

Project record: An isolated Samba service, synthetic users, a read-only share, credential and authorization failures, the intended access change, and a repeated file read.

Interactive view

Find the first gate that rejects the request.

Connectivity is available in every state. The difference is whether the request stops at authentication or share authorization.

Choose a view

The SMB service answers, but session authentication fails.

  1. 01
    SMB serviceReachable
  2. 02
    CredentialsSession setup
  3. 03
    Share rulevalid users
  4. 04
    FilesystemGroup and mode
  5. 05
    Sentinel fileRead test

Access checks

Test connectivity, authentication, share rules, and filesystem access in that order.

  1. 01

    Create two synthetic users and one read-only support share on an internal Docker network.

  2. 02

    Record a wrong-password failure for the allowed user.

  3. 03

    Use the second user’s correct password and record the separate share authorization failure.

  4. 04

    Add only that user to the allowed share and filesystem group, reload the configuration, and repeat the file read.

  5. 05

    Confirm that an unknown user still fails authentication.

Evidence from the lab

The checks used to reach the conclusion.

Selected outputs from the lab. Sensitive and unnecessary details are omitted.

session setup failed: NT_STATUS_LOGON_FAILURE
E01 · Captured lab outputCredential failureThe allowed account reaches SMB but fails session setup when the password is wrong.
View artifact Back to C01 
tree connect failed: NT_STATUS_ACCESS_DENIED
E02 · Captured lab outputAuthorization failureThe second account authenticates but cannot connect to the support share.
View artifact Back to C01 
[support]
path = /srv/support
valid users = labuser auditor

auditor groups: auditor, labuser
share mode: 0750
E03 · Captured lab outputCorrected access boundaryThe share now names both synthetic users, and the second account belongs to the filesystem owner group.
View artifact Back to C02
Full evidence archive4 additional artifacts
readme.txt  25 bytes
controlled support share
getting file \readme.txt of size 25
E04 · Captured lab outputRead after correctionThe previously denied account lists the share and reads the controlled sentinel file.
View artifact Back to C02 
controlled support share
getting file \readme.txt of size 25
E05 · Captured lab outputSeparate session retestA new SMB client process reads the same 25-byte sentinel file.
View artifact Back to C02 
Public package
• credential and authorization failures
• corrected share configuration
• correction and separate retest
• SHA-256 checksums
E06 · Captured lab outputEvidence checksumsThe public package covers both failures, the corrected configuration, the file reads, and the environment record.
View artifact Back to C01 
session setup failed: NT_STATUS_LOGON_FAILURE
E07 · Captured lab outputUnknown user remains deniedA separate request from a nonexistent account still fails session setup after the intended access change.
View artifact Back to C02

Result and limits

What changed, and what this lab does not prove.

Result

The wrong password returned a logon failure. The valid but unauthorized user reached the SMB service and received access denied. After the group and share change, that user read the sentinel file in two separate sessions. A separate negative test confirmed that a nonexistent account still failed session setup.

Limit

This is one Samba server and a synthetic read-only share. It does not claim Windows Server, DFS, production NTFS, Kerberos, or domain administration.

Claims and evidence

What the evidence supports.

The lab produced distinct logon-failure and access-denied results for the same reachable SMB service.

The identities and share exist only inside the isolated lab.

EvidenceE01E02
After the share and group change, the previously denied user read the sentinel file in a separate retest, while an unknown user still failed session setup.

The retest proves read access to one controlled file.

EvidenceE03E04E05E07