[Help] Captcha won't validate — unable to log into TOS from desktop PC - captcha fails, mobile & SSH login works fine

[detritusuk]

Device: TerraMaster F5-422
TOS Version: 5.1.67 (build 5.1.67-00214)
BIOS/InitBoot: MAPL0304V22

Issue started after running a system settings backup export from the web UI — it hung on a persistent spinner, and I opened a second browser session to check on it before the first had finished. Since then, logging in from my desktop PC fails every time: after a couple of attempts it demands a 4-digit captcha, and the captcha is then rejected regardless of whether it's entered correctly.

Logging in from my phone's mobile browser, on the same wifi network, works perfectly with no captcha at all — including after an explicit logout and fresh login — so the account and password are clearly valid.

Throughout all of this, file shares remain fully accessible via SMB and Plex (on a separate machine, reading from the NAS shares) continues working normally, so the storage pool and data are unaffected.

Troubleshooting tried on the PC side, all with no change:

Incognito/private browsing
A completely different browser (Chrome vs Brave)
Clearing browser cache
Renewing the PC's IP address (ipconfig /release + /renew)
Overriding the PC's MAC address
Emulating a mobile device/User-Agent via DevTools (confirmed the same JS app bundle is served regardless of device — no separate mobile template exists)
Power cycling the PC
Full power cycle of the NAS itself (waited over an hour for full boot)
System clock sync (confirmed matching between PC and phone)

Follow-up on your suggestions:

Account Blocking list: Checked Control Panel → General Settings → Security → Account → Block List via a working mobile session. Empty — no IP addresses listed at all.
iptables: Enabled SSH, connected as my admin account (Stephen) — authenticates fine over SSH too. Ran iptables -L -n -v before making changes: no entries referencing port 8181 or my PC's IP anywhere in the ruleset, only generic DOS-protection rules and SSH/Telnet LAN-only restrictions. Ran iptables -F as instructed — no change to login behaviour, consistent with there being nothing there to clear.

Current assessment: IP, MAC, browser, incognito, cache, User-Agent/device emulation, clock sync, the Account Blocking list, and firewall rules are all ruled out. The one consistent fact throughout is which physical device is making the request. This points to an application-layer issue — session or account state in the database, or the captcha validation logic itself — rather than anything network, device, or client-side.

My honest read at this point is that the desktop captcha validation itself is the actual fault — it's rejecting correct input consistently, on a device where nothing else about the request differs from a working one. If this is a known issue that's already been addressed in a later TOS release, that would save us both time: could you confirm whether this specific captcha validation bug has been fixed in a subsequent version, and if so, which one? If it's not already fixed, could someone check the account/session database directly, or advise on resetting login/session state for this account without a full system reinstall?

[EriChan]

To help us accurately diagnose this issue and confirm whether there is an anomaly within the TOS system, we recommend scheduling a remote technical support session with our engineering team.

Please contact our online technical support via the link below. When reaching out, be sure to include this forum post link and your forum ID so our engineers can quickly reference your context and assist you directly:
https://salesiq.zohopublic.com/signatur ... 97d0be8892

Thank you for your patience and cooperation!

[detritusuk]

I cannot tell you how many times I tried to go through the captcha process. It just failed. Rebooting, leaving a gap, it just consistently failed even when you knew there was no ambiguity with the captcha.

Today I tried the captcha whilst I was trying your link for tech support, having probably tried the captcha process about 20 times or more in total and it worked. No support needed.

No rationale. It just authenticated.