Samba
An internal SMB service at Oxfredy University was failing silently — lecturers could not upload, students could not access. Three layered misconfigurations in smb.conf were operating against each other. The restrictive protocol floor looked like the obvious suspect, but was not the cause. The real failure was a deprecated authentication mode still active in the runtime configuration, combined with an orphaned valid users declaration that had been commented out of the share block.
Executive Summary
Lecturers reported they could not upload to the [lessons] SMB share. The assigned role was system administrator, not incident responder — the objective was to identify the misconfiguration, correct it, and restore access under appropriate user authentication.
Review of /etc/samba/smb.conf surfaced three separate problems: server min protocol = SMB3 set an unusually high floor; security = share (deprecated, anonymous-access style) was still active in the global section; and the [lessons] share's valid users directive had been commented out, leaving no explicit user authentication for the share. The fix required resolving all three, but only one of them was actually the root cause of the upload failure — and the triage sequence mattered for that reason.
After corrections and a service restart, the share accepted per-user authenticated access, and the lesson file in the share was recovered and validated.
Findings & Analysis
commented out
valid users = %S but the line was commented. With security = share active globally and no explicit per-share user list, the share had no meaningful authentication enforcement path.service smbd
sudo -l. The assigned user could start, stop, restart, and query the smbd service without a password, which was required to apply the configuration fix and validate the repair.33e2bb43ea4e40fa8259
b203c46e418a
/home/smbuser/share/ after corrected configuration and service restart. File contents validated against the expected submission flag.- Config file: /etc/samba/smb.conf
- Share path: /home/smbuser/share/
- Service: smbd (managed via
service smbd restart) - Authentication target: smbuser (per-user auth, least privilege)
- Recovered file: lessons-11.txt
Tools & Technologies
service smbd was the only privileged path available — knowing that up front shaped what the fix could look like.smb.conf changes to take effect; a failed restart would have indicated a syntax error in the edits before any functional test was run.cd / ls / cat to validate the corrected share path was reachable, the target file was present, and the lesson content was readable under the new authentication rules.Investigation Process
Five steps. The defining move was not any of the fixes — it was deciding, during configuration review, which of three visible misconfigurations was actually responsible for the failure and which were noise.
Why: Establish what the assigned user can actually do before touching anything. Response: (root) NOPASSWD: /usr/sbin/service smbd start|stop|restart|status. This defines the scope of the repair — the user can restart the service, but cannot install packages or escalate further.
Why: Read the config in full. Three candidate issues surfaced: server min protocol = SMB3 (restrictive floor), security = share (deprecated auth mode, still active), and [lessons] with valid users = %S commented out. Rather than patching all three as equally suspect, triage which one actually caused the failure.
The restrictive protocol floor was the most visually conspicuous misconfig and therefore the easy suspect. But a protocol floor that's too high produces a different failure mode — clients unable to negotiate a session at all — not the silent upload-permission failure that was reported. The actual failure pattern matched authentication resolution: security = share was still active globally, which meant share-level (not user-level) enforcement, while the [lessons] share's valid users line was commented out. The share had no per-user authentication path to enforce. That was the cause. The protocol floor still needed to be fixed, but it was not why the lecturer could not upload.
Why: Three discrete edits to the same file. Lower the protocol floor so legacy clients can negotiate; remove the deprecated security = share from the runtime path; uncomment valid users so the share has an explicit authentication enforcement target. All three are required for a clean configuration — but only the second and third are required for the reported failure to resolve.
Why: Configuration changes to smb.conf do not take effect until smbd reloads. A failed restart at this point would indicate a syntax error in the edits and catch the problem before a functional test; the restart succeeded cleanly, which is the first positive signal that the configuration is valid.
Why: Functional validation. If the configuration fix actually resolved the authentication path, the share directory is reachable and the target file is readable. Contents confirmed the expected flag, closing the case. The upload permission that the lecturer originally reported would now resolve on the same authentication path.
Recommendations
security = share that have been removed from mainline Samba should be stripped out during any config audit, not left commented or hanging. An active deprecated directive is worse than one that's been explicitly deleted — it ambiguates the authentication model and creates exactly the layered-misconfiguration failure mode seen here.valid users explicitly, not rely on global defaults or on placeholder values like %S that require a particular interplay with other directives to behave. Least-privilege authentication works only when it is stated at the share level.Technical Note
Three misconfigurations were visible in smb.conf, but only two of them were causally linked to the reported failure. The restrictive protocol floor (server min protocol = SMB3) was the most conspicuous — it looks wrong at first read, and fixing it feels productive. But a protocol-floor mismatch produces a negotiation-level failure: clients cannot establish a session at all, and the failure surfaces before authentication. The reported failure was specifically at the authentication stage: lecturers could reach the share but could not upload. That pattern pointed away from protocol and toward the combination of security = share (deprecated, ambiguous authentication model) with valid users commented out of the share block (no enforcement target).
The operational value of distinguishing these before patching is that the next SMB incident in the same environment will be triaged on the same symptom-to-cause mapping, not by reflexively patching whichever directive looks most wrong.
References
- Samba
smb.confman page. Authoritative reference for share-level directives, authentication modes, and protocol negotiation options. samba.org - Deprecation of
security = share. Share-level security was removed from mainline Samba; the directive persists in legacy configurations but no longer has the behavior the original design intended. Samba release notes and documentation cover the history. - CIS Benchmark — SMB/Samba hardening. Baseline hardening guidance for SMB services in Linux environments, including protocol floors appropriate to the client population. cisecurity.org