Tech Log Entry — LAN File Sharing (after upgrade to unmanaged switch)
Tech Log Entry — LAN File Sharing
(or, SMB Between Windows 11 Desktop and Linux Mint Laptop)
Background and Context
With the three-machine automated backup infrastructure complete, the next practical need was interactive file sharing — a way to move files between the Windows 11 desktop and the Linux Mint laptop #1 without USB drives (cumbersome) or email (insecure). The two machines are connected via a dedicated gigabit LAN switch on an isolated local subnet (192.168.2.x), separate from the home Wi-Fi network.
Goal: a shared folder accessible from both machines, with one-click access from each side, backed by proper credentials and restricted to the private LAN only.
Security note: The Linux laptop #2 was deliberately excluded from this setup per its isolation policy — it hosts Claude Code and is kept off persistent shared network folders by design. File transfers from/to it will be done manually via USB, for now.
Software and Protocol
SMB (Server Message Block) — the Windows-native file sharing protocol; also supported by Linux via Samba
Samba — already installed on laptop #2 from a previous direct ethernet file transfer setup
Windows File and Printer Sharing firewall rules (built into Windows 11)
Windows Network Discovery (built into Windows 11)
LLM used: Claude Sonnet 4.6 [Pro plan]
CompTIA Network+ study note: SMB is a core file sharing protocol covered under Network Implementations. Understanding SMB versions (SMB1, SMB2, SMB3), their security implications, and how they interact across operating systems is directly tested material. SMB2 was confirmed enabled on the desktop via PowerShell — SMB1 is deprecated and disabled by default on modern Windows for security reasons.
Setup Steps
On the desktop (Windows 11):
Enabled File and Printer Sharing and Network Discovery firewall rules for the Private network profile via PowerShell:
powershell
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Private
Set-NetFirewallRule -DisplayGroup "Network Discovery" -Enabled True -Profile Private
Created shared folder: D:\SHARED-[desktop]-[laptop #1]
Security tab permissions: Users group — Full Control, Modify, Read & Execute, Read, Write
Advanced Sharing: share name SHARED-[laptop #1]-[desktop], maximum 2 simultaneous users
Share permissions: shareuser — Full Control
Created dedicated local service account shareuser for share authentication:
Added to local Users group
Password required: Yes
Password never expires
User may not change password
No administrator rights
On [laptop #1] (Linux Mint / Nemo file manager):
Connected via SMB path: smb://192.168.2.1/SHARED-[laptop #1]-[desktop] Authenticated with shareuser credentials (domain: [desktop]) Bookmarked in Nemo sidebar for one-click access
Troubleshooting — Authentication Failures
This setup required more troubleshooting than expected. The authentication issues and their resolutions are worth documenting in detail.
Issue 1: Hostname not resolving File Explorer path \\Desktop-Q4PNAMF\SHARED-[laptop #1]-[desktop] failed. IP-based path \\192.168.2.1\SHARED-[laptop #1]-[desktop] worked. Resolution: use IP address rather than hostname for LAN SMB access. Hostname resolution via NetBIOS/LLMNR was inconsistent on this subnet configuration.
Issue 2: Microsoft account password rejected Initial attempt used the Microsoft account password (hotmail.com account linked to Windows). SMB network authentication on Windows 11 with a Microsoft account is complex — the Microsoft account password does not straightforwardly authenticate local SMB shares. Resolution: created a dedicated local Windows account (shareuser) specifically for share access, separating share credentials from the primary account entirely. This is better security practice regardless.
Issue 3: shareuser account not in Users group New local accounts on Windows 11 are not automatically added to the local Users group. The Users group membership is required for network logon (Logon Type 3). Confirmed via net user shareuser output showing empty Local Group Memberships. Resolution: Add-LocalGroupMember -Group "Users" -Member "shareuser".
Issue 4: Password required set to No net user shareuser showed Password required: No despite a password being set during account creation. Windows SMB blocks network authentication for accounts without a password requirement as a security measure. Resolution: net user shareuser /passwordreq:yes.
Issue 5: Special characters in password causing mismatch After fixing Issues 3 and 4, authentication still failed. Event Viewer Security log (Event ID 4625, Sub Status 0xc000006a) confirmed the failure reason was wrong password. Root cause: the password was set via PowerShell's ConvertTo-SecureString, which interprets special characters differently than intended — the password stored in Windows didn't match what was typed. Resolution: reset password using net user shareuser [password] directly, which handles the string without special character interpretation. Generated a 25-character letters-and-numbers-only password via Bitwarden to avoid future escaping issues. [Note: This issue with special characters has arisen a dozen times or more now with complicated applications.]
Diagnostic tool that identified the root cause:
powershell
Get-EventLog -LogName Security -Newest 20 | Where-Object {$_.EventID -eq 4625} | Select-Object -ExpandProperty Message
Event ID 4625 (failed logon) includes Sub Status codes that identify the exact failure reason — in this case 0xc000006a (wrong password) vs 0xc0000064 (unknown username) vs 0xc000006e (account restriction). Reading the Sub Status code directly rather than guessing saved significant troubleshooting time.
CompTIA Network+ relevance: Authentication troubleshooting, NTLM vs Kerberos authentication, Windows logon types (Type 3 = network logon), and reading security event logs are covered under Network Security and Network Troubleshooting. The structured approach used here — check logs, read error codes, isolate variables — directly mirrors CompTIA's troubleshooting methodology. Event ID 4625 and its Sub Status codes are worth knowing for any Windows network environment.
Final Configuration
Daily Use
[desktop]: click SHARED-[laptop #1]-[desktop] in Quick Access — folder opens directly, no authentication needed
[laptop #1]: click share bookmark in Nemo sidebar — may prompt for shareuser credentials after reboot; enter and optionally save to keyring
After the other machine adds files: press F5 in Nemo to refresh — SMB network mounts don't auto-refresh the directory listing the way local folders do
[laptop #2]: not connected to this share; USB drives (requiring Human-In-The-Loop [i.e., HITL]) used for any necessary file transfers per isolation policy
Watch Out For (Future)
Linux Nemo does not auto-refresh SMB share contents — always press F5 after the other machine adds files before concluding something is missing
SMB credentials may not persist across [laptop #1] reboots — re-enter shareuser credentials if prompted; select "Remember password" if the option appears
The share is only accessible when both machines are on the LAN — [laptop #1] cannot reach it when traveling or when [desktop] is off
shareuser credentials stored in Bitwarden — retrieve from there if forgotten
If the shared folder is accidentally deleted from D:, re-create it and re-run the Advanced Sharing setup; the Quick Access pin and Nemo bookmark will need to be updated to the new share
Lessons Learned
Read security event log Sub Status codes before guessing at authentication failures. Query code numbers on Google search; question LLMs with full messages.
Event ID 4625 with Sub Status 0xc000006a means wrong password — not wrong username, not account locked, not policy restriction. Knowing the specific code eliminates entire categories of troubleshooting.
PowerShell's ConvertTo-SecureString interprets special characters in ways that can produce a different stored password than intended. For setting local account passwords, net user [account] [password] is more reliable and predictable.
Dedicated service accounts for specific purposes (shareuser for file sharing, backupuser for SSH backups) are better practice than reusing primary account credentials. Each account has minimal permissions (“least privilege”, etc) for its specific function, reducing risk if credentials are ever compromised.
IP addresses are more reliable than hostnames for LAN access on small unmanaged networks without a dedicated DNS server. NetBIOS and LLMNR name resolution can be inconsistent.
Next Steps / To-Do
Install VPN on [laptop #1] and [laptop #2] (WireGuard-based; travel deadline approaching)
Install Bitwarden Firefox extensions on [laptop #1] and [laptop #2]
Begin Claude Code introductory projects on [laptop #2]
Evaluate and uninstall CUDA toolkit on [desktop]
Address C: drive storage on [desktop] (88% full)
Complete reused-password cleanup in Bitwarden
Comments
Post a Comment