[10:02] Customer: Hi, after updating my self-hosted photo library last night, the web app is showing “Unable to load timeline.” The mobile app still uploads photos, but I can’t view anything.

[10:03] Support: Hi! I can help with that. Which version did you upgrade from and to, and how is the application deployed?

[10:04] Customer: Docker Compose on Ubuntu 24.04. I upgraded from 1.128.0 to 1.130.2.

[10:05] Support: Thanks. Are all containers running? Please share the output of `docker compose ps`, with any private hostnames or IP addresses removed.

[10:07] Customer: Everything says “Up” except `photo_server`, which keeps restarting.

[10:08] Support: That explains the timeline error. Could you check the last 50 lines from that container with `docker compose logs --tail=50 photo_server`?

[10:11] Customer: The repeated error is: `password authentication failed for user "postgres"`.

[10:12] Support: It sounds like the database password available to the server container no longer matches PostgreSQL. Did you change your `.env` file during the upgrade?

[10:13] Customer: I copied the new example file over the old one and then filled in what I remembered. I probably generated a new database password.

[10:14] Support: That would cause this. PostgreSQL keeps the password originally used to initialize its data volume; changing only the environment file doesn’t update the existing database user.

[10:15] Customer: Is there a way to recover without losing the library? It has about 80,000 photos.

[10:16] Support: Yes. Don’t remove the database volume or run `docker compose down -v`. Your photos and database should remain intact. If you have a backup of the previous `.env`, restore the old database password there first.

[10:18] Customer: Found `.env.bak`. The old `DB_PASSWORD` is different.

[10:19] Support: Great. Replace the current `DB_PASSWORD` value with the old one, save the file, and recreate the application containers using `docker compose up -d`. This should not delete any data.

[10:22] Customer: Done. `photo_server` is staying up now, but the page still shows the same error.

[10:23] Support: Please hard-refresh the browser or sign out and back in. Also check whether the server logs show any new errors after startup.

[10:25] Customer: After signing back in, the timeline loaded. Some thumbnails are gray for a few seconds, but they eventually appear.

[10:26] Support: That’s expected immediately after an upgrade if thumbnail jobs are being processed. You can check the Administration → Jobs page to confirm the thumbnail queue is decreasing.

[10:28] Customer: It shows 4,312 thumbnail jobs active or waiting. CPU usage is pretty high.

[10:29] Support: That’s normal while the queue runs. If the server is needed for other tasks, you can reduce job concurrency from the administration settings. Otherwise, let it finish and CPU usage should return to normal.

[10:30] Customer: Uploads made during the outage are showing up too. Does that mean everything is safe?

[10:31] Support: Yes, that’s a good sign. The mobile app likely uploaded the original files successfully, while the unavailable server container prevented the timeline and processing jobs from working. I’d still recommend creating a fresh database backup once the job queue finishes.

[10:32] Customer: Understood. Thanks for catching the password issue.

[10:33] Support: You’re welcome! As a precaution, keep the working `.env` backed up securely and avoid replacing it wholesale during future upgrades. Update only the variables called out in the release notes.