mirror of
https://github.com/healthchecks/healthchecks.git
synced 2026-04-25 06:55:53 +03:00
[GH-ISSUE #637] User Account and Checks Missing #461
Labels
No labels
bug
bug
bug
feature
good-first-issue
new integration
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/healthchecks#461
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mathmaniac43 on GitHub (Apr 16, 2022).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/637
Hello,
I went to sign into my self-hosted Docker container Healthchecks v1.25.0 instance for the first time in a few weeks to work on connecting it to my HomeAssistant instance... and my login wouldn't work, which was really weird. I went into the container to mess around, and it wouldn't let me change my account's password, but eventually it allowed me to create a new account with my username, so I think somehow my account got deleted/lost.
Any ideas how to diagnose what might have happened, or has anyone experienced anything similar before? I have periodic backups that I am going to try a few of and see if I can get things back to a prior working state, but this seems like a significant-enough issue that I want to try to understand it.
Thank you.
@mathmaniac43 commented on GitHub (Apr 16, 2022):
Never mind... I checked my backups, and there wasn't anything in them. I think I configured my container to use SQLite, but did the Docker voluming to back up postgreSQL, so nothing was actually captured! Going to set things back up fresh using v2.0.1, make sure the voluming works and the database is actually backed up, and should be good to go after that.
@mathmaniac43 commented on GitHub (Apr 16, 2022):
In case someone has a similar issue: in addition to volume-mapping the correct directory (
/tmp), I did have to make sure that the permissions were correct in order to write the database into it. Got the hint for that fix here.