Settings That Outlived Their Reason

Settings That Outlived Their Reason

Search terms: stale config · why is this slow · worked before · no symptom · vers=2.0 · hosts allow · old subnet · workaround · legacy setting · configuration drift

A failure class worth naming, because it doesn’t announce itself. A setting that was correct when written, became wrong when the environment changed, and produced no symptom until something finally needed it.

Nothing is broken. Nothing logs an error. The config looks deliberate — because it was deliberate. It’s just answering a question nobody is asking anymore.

Three real cases, all found the same weekend

vers=2.0 — the vendor that got replaced

//10.0.0.15/... /mnt/nas1 cifs ...,vers=2.0,...

Correct when written: the NAS was a Synology that genuinely couldn’t negotiate SMB 3.0. Setting vers=3.0 back then broke the mount — the workaround was real and necessary.

What changed: the Synology was replaced by a UGREEN that speaks SMB 3.0 fine.

Why it hid: the mounts kept working perfectly. SMB 2.0 caps the negotiated buffer at 64 KB; SMB 3.0 allows 4 MB. Every read was being chopped into 64× more round trips than necessary, and the only visible effect was “the NAS feels a bit slow” — which is not a symptom anyone files a bug about.

Cost: 64× smaller transfer buffers, for roughly two years.

hosts allow = 192.168.1.0/24 — the router that got replaced

Correct when written: a deliberate hardening step, restricting Samba to the LAN.

What changed: the mesh router was swapped for one supporting more devices, and the LAN moved from 192.168.1.x to 10.0.0.x.

Why it hid: nothing on the LAN had tried to connect to that server since. The NAS mounts that broke visibly got fixed; this broke invisibly and stayed broken. When a client finally did connect, it failed at protocol negotiation — presenting as a mysterious network error rather than an access-control one, which sent the search in the wrong direction entirely.

Relative image paths — the folder that got reorganised

![git status](images/gitstatus.png)

Correct when written: the images lived inside the page bundle, so a relative path resolved.

What changed: images were moved to a shared section folder one level up.

Why it hid: stale build output and browser cache kept serving the old files. The page rendered perfectly for over a month while being genuinely broken. It only surfaced when a new image was added — no cached copy existed, so it showed as blank space. Adding the new file didn’t break anything; it revealed what was already broken.

The shared shape

  1. The setting was right when written — this is not carelessness
  2. Something in the environment changed: hardware, vendor, network, layout
  3. The obvious dependents broke and got fixed
  4. This one had no dependent that noticed
  5. It kept working “well enough” — or wasn’t exercised at all
  6. Discovery came from an unrelated question months or years later

The dangerous middle is step 5. A setting that fails loudly gets fixed the same day. A setting that degrades quietly, or that nothing currently exercises, can persist indefinitely.

How to find them

Audit config against current reality, not against itself. A config file is internally consistent by definition — the question is whether it still matches the world.

# Network assumptions vs the actual LAN
ip -4 addr | grep inet
grep -rniE "192\.168\.|10\.0\.|172\.(1[6-9]|2[0-9]|3[01])\." /etc/samba/ /etc/fstab /etc/hosts 2>/dev/null

# Version pins and workarounds — each should have a reason that still holds
grep -rniE "vers=|proto|min protocol|max protocol|legacy|compat" /etc/fstab /etc/samba/ 2>/dev/null

# Paths pointing at things that no longer exist
awk '$1 !~ /^#/ && NF>1 {print $2}' /etc/fstab | while read -r m; do
  [ -n "$m" ] && [ "$m" != "none" ] && [ ! -d "$m" ] && echo "MISSING mountpoint: $m"
done

Trigger points worth a config sweep — anything that changes the environment underneath:

  • replacing a router, switch, or changing the subnet
  • replacing a NAS, drive, or server
  • an OS release upgrade
  • moving a service to a different host
  • any workaround you wrote for a specific product version

Write down why, not just what. vers=2.0 alone is undecipherable years later. vers=2.0 # Synology DS-whatever can't negotiate SMB3 — retest if the NAS is replaced carries its own expiry condition. A comment that names the reason tells a future reader when the setting stops being true.

A close cousin, worth recognising together — something old lying around makes a broken thing look correct:

Stale thing What it hid
public/ build output Hugo never cleans A broken image path, for a month
Browser image cache The same, even after a clean rebuild
A second hugo server on another port Edits appearing to have no effect
A tool’s own “success” message A redaction that redacted nothing

Same defence in every case: check the artifact, not the summary. Build into a clean directory. Hard-refresh. curl for an HTTP code and a byte count. Grep the output file for the string that should be gone. A convenient-looking report is not evidence.