Before changing anything#
Keep the existing encrypted state where possible. Read the failure category. Distinguish a missing device key, an invalidated device key, an expired profile, revoked permission and damaged local storage.
Do not post raw logs, full profiles, secrets, DNS questions or browsing destinations in a public issue. Use a previewed, redacted diagnostic summary where the native workflow supports it.
Device backups and deployment recovery are different#
| Boundary | Recovery responsibility |
|---|---|
| Android device | Use a supported encrypted-backup and explicit restore flow. Review the intended records before applying. A browser-demo backup is not an Android recovery artifact. |
| Deployment owner | Keep the encrypted root recovery artifact and current encrypted backups off the VPS. The owner controls deployment recovery. |
| Website preview | Only synthetic demo state is involved. It cannot recover real keys, profiles or a VPS. |
Do not weaken a check to get connected#
Certificate, signature, expiry, revocation, replay, downgrade and rollback checks must not be weakened for convenience. The remedy for an inappropriate profile is an appropriate owner-issued one, not a hidden bypass.
Checks after an owner operation#
kurdctl doctor --data-dir /var/lib/kurd-nodeWhere: the configured owner system. When: after clock changes, storage recovery, upgrades or permission changes. Effect: inspect local consistency; it is not a generic permission to reset or re-key.
On failure, preserve state and follow the source guide. The guide requires the offline recovery artifact for clock repair.
Source and scope
Reviewed . The linked source describes the implementation; released-build evidence is a separate check.