[Help] F2-425 TOS 6.0.794 — root/jaysmith01 UID swap + recurring WebDAV share failure after power loss

[jaysmith01]

Device: F2-425, TOS 6.0.794-01324
No UPS attached — device is on direct wall power, has been through multiple power outages recently.

Summary
Two related issues, both appearing after unclean power loss:

1) A specific shared folder ("Joplin", used for a WebDAV note-sync client) stops resolving over WebDAV, while the WebDAV service works fine otherwise.
2) My regular login account's UID has been swapped with root's — a serious permissions/security issue found while investigating #1.

Issue 1 — recurring WebDAV failure on one shared folder
Client requests return 404 on the exact same two paths every time:

Code: Select all

GET https://<device>:474/Joplin/.sync/version.txt  -> 404 Not Found
GET https://<device>:474/Joplin/info.json          -> 404 Not Found

An unauthenticated request to the same host correctly returns 401, so the WebDAV daemon itself is up and enforcing auth normally — the 404 is specific to this one share's contents.

The folder itself is fine: /Volume1/Joplin exists, 14,726 files, ~2.1GB, owned by my account, correct permissions, contains the .sync/ and .resource/ subfolders the WebDAV client itself created.

This has recurred at least 5 times since Aug 5, 2026 (distinct clusters, each recovering before the next), and the current episode has NOT been fixed by any of:
- Toggling "Enable WebDAV server" off/Apply/on/Apply (confirmed this genuinely restarts the daemon — new PID, systemctl start time matches)
- Checking the folder's Permissions tab (my account has Read/Write — fine)
- Deleting and recreating the folder's WebDAV client rule (was already "* : Allow")
- A full device reboot (Shut Down via GUI, then powered back on) — identical 404s resumed immediately

I couldn't find a flat config file controlling this mapping in TOS 6 — /etc/webdav_conf.ini only holds the global port/enable settings. Searching pointed at a PostgreSQL instance backing share config instead, which I didn't want to touch directly without guidance.

Issue 2 — root/jaysmith01 UID swap
Found while troubleshooting why "sudo systemctl restart webdav.service" over SSH failed with "Interactive authentication required":

Code: Select all

$ id
uid=0(jaysmith01) gid=0(jaysmith01) groups=0(jaysmith01),997(allusers),998(admin)

$ sudo -n id
uid=9999(root) gid=9999(root)

My regular account (jaysmith01) currently has UID 0 — root's UID. The actual root account has been reassigned UID 9999. This also explains why nearly all of /usr displayed as "owned by jaysmith01" (the files were never touched — UID 0 just resolves to a different username now), and why /usr/libexec/polkit-agent-helper-1 lost its setuid bit (still owned by jaysmith01, no 's' bit), breaking polkit-based auth for systemctl over SSH:

Code: Select all

polkit-agent-helper-1: needs to be setuid root
Error: Incorrect permissions on /usr/libexec/polkit-agent-helper-1 (needs to be setuid root)

This persisted across a full device reboot, so it's corrupted on-disk state, not transient.

What I'm asking
1. Safe way to fix the root/jaysmith01 UID swap without further destabilizing the account database
2. Safe way to restore polkit-agent-helper-1's correct ownership/setuid bit
3. Where the WebDAV folder-to-path mapping actually lives in TOS 6, and how to repair it for just this one share
4. Whether this is a known issue with TOS 6.0.794 after unclean shutdowns

I have a fuller write-up with exact timestamps and a TOS-generated system report ready to attach if useful — my direct email to [email protected] bounced due to a Gmail content-scan block on the attachment, which is why I'm posting here instead.

[CursaYang]

During initialization, the super administrator account created in TOS replaces the traditional root user and becomes the highest-privilege account.
Regarding the issue you mentioned, it may be related to a file system anomaly caused by an abnormal power outage. You can upload the system report to a cloud drive, then include the share link and the link to this post in the body of the email. We will analyze it further.