Bottom Line: This Was a Route-Specific Files UI Failure, Not a General Storage Failure
Local access worked while the same Files app failed through the Tailscale address. That isolates the problem to the remote HTTP/WebSocket/session path rather than the disks or Files database. In the original 1.4.4-beta1 case, upgrading to stable 1.4.4 removed the error.
Current ZimaOS Officially Supports Tailscale as a Standard Remote-Access Path
The September 2026 ZimaOS Tailscale guide says any tailnet device can reach the ZimaOS server through its 100.x address. Use that current setup before applying beta-era workarounds.
The Tailscale hardware guide provides the current app-side context.
When the Dashboard Opens but Files Says Error Loading
Open browser developer tools and check failed API/WebSocket requests. Also test the same 100.x address from another tailnet client. Tailscale's routing documentation and CLI reference help distinguish direct tailnet access from subnet routing.
Do Not Reinstall ZimaOS as the First Fix
A later user on 1.5.4 said reinstalling solved a similar symptom, but that is a high-cost fix and does not identify the cause. First update to the current stable ZimaOS release, restart the Tailscale app, verify the 100.x route and compare local versus tailnet browser requests.
Use Built-In Remote Access as a Control Test
If ZimaClient remote access works while Tailscale Files does not, you have strong evidence that storage and the Files service are healthy. The ZimaClient remote-access guide is a useful control path, and the ZimaOS app guide helps when the Tailscale container itself needs refresh.
