From 1a259e0895ae5f25cb5eddecebeb28588e105e10 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 10 Aug 2026 19:35:57 +0000 Subject: [PATCH] Fix password prompt silently stripping leading/trailing whitespace MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reported live: mount error(79) again despite already switching to real credentials + sec=ntlmssp — this time with a Samba password containing special characters. Root cause confirmed directly: `read -r -s pw1` without `IFS=` silently strips leading/trailing whitespace even when reading into a single variable (verified: " P@ss word! " -> "P@ss word!", 10 chars instead of 12). A password with a leading/trailing space — common from a password manager's copy-paste, or a stray keystroke — got quietly trimmed on the way into the credentials file, so it no longer matched what was actually set on the Samba account. That mismatch surfaces as this same cryptic ENOKEY mount error, not an obvious "wrong password". Fixed with IFS= on both reads. Also echo the captured length (never the password itself) right after entry, so a silently-stripped character is something you can catch and cross-check yourself before the mount even attempts, instead of only after it fails. --- services/vpn-data-mount.sh | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/services/vpn-data-mount.sh b/services/vpn-data-mount.sh index e10b526..d6e436a 100644 --- a/services/vpn-data-mount.sh +++ b/services/vpn-data-mount.sh @@ -293,11 +293,23 @@ _vdm_find_existing_smb_password() { _vdm_prompt_password() { local prompt="$1" pw1="" pw2="" while true; do + # IFS= matters here, not just -s/-r: plain `read -r pw1` (no IFS=) + # silently strips leading/trailing whitespace even into a single + # variable — confirmed live, a password with a leading/trailing + # space (copy-pasted from a password manager, a stray keystroke) + # got quietly trimmed on the way in, so the credentials file ended + # up holding a DIFFERENT password than the one actually set on the + # Samba account. That surfaces as a cryptic mount failure, not an + # obvious "wrong password" — nothing here could tell the two apart. echo -n " ${prompt}: " >&2 - read -r -s pw1; echo "" >&2 + IFS= read -r -s pw1; echo "" >&2 echo -n " Confirm: " >&2 - read -r -s pw2; echo "" >&2 + IFS= read -r -s pw2; echo "" >&2 if [ -n "$pw1" ] && [ "$pw1" = "$pw2" ]; then + # Length only, never the password itself — lets you catch a + # silently-stripped character (or a typo) yourself before the + # mount attempt fails with an unhelpful error. + echo " Captured (${#pw1} characters)." >&2 printf '%s' "$pw1" return 0 fi