Unraid Community Application Database Errors

[joecksma]

🐛 Bug Report

• 📁 I've Included a ZIP file containing my librephotos log files
• ❌ I have looked for similar issues (including closed ones)

📝 Description of issue:

After installing the Unraid Community Application the Frontend starts but is unable to get user information from the database. The database appears to be empty (e.g. not containing any tables). This results in being unable to login, without any visible error on the page, but with errors in the logs and browser console.

FATAL:  role "librephotos" does not exist
ERROR:  relation "constance_config" does not exist at character 91

psycopg2.errors.UndefinedTable: relation "api_user" does not exist

Logs: logs.zip

🔁 How can we reproduce it:

• Fresh install from Unraid Community Applications with new data directory. Try to login.

Please provide additional information:

• 💻 Operating system: Unraid 6.10.3
• ⚙ Architecture: x86
• 🔢 Librephotos version: reallibrephotos/singleton:latest via Unraid Community Applications
  DIGEST:sha256:e15ede7cbfe4568b2090d9d99a15fee95960e825f3d73b5e11fc7990ddf14702
• 📸 Librephotos installation method: Docker
  • 🐋 tag: latest, Digest: e15ede7cbfe4
  • 🐋 Docker Version: 20.10.14
• 📁 How is you picture library mounted: Local XFS (but it is empty)

[lilfade]

Just setup today with no issues, Unraid 6.10.3 via community apps ... it took forever and tapped out my initial docker image size first before it actually installed.

[robertpro]

I'm having exactly the same error

[Isengrim95]

same error here :(

[cajunjoel]

I have the same problem and I'm trying a few things to resolve it, but I'm going to throw this out there. I think the initial set up takes a long time. Like, more than a few minutes. In adding LibrePhotos to unRAID the process of downloading, verifying, extracting, etc etc took a long time. I reloaded the page instead of waiting for it to finish.

I dug into the contents of the Docker image and found that the initialization script "install-librephotos.sh" took 10-15 minutes to run. It's doing a lot, so the est I can suggest is to restart LibrePhotos in unRAID and wait a good 15-20 min before trying to log in.

And be sure to check the logs in unRAID. That will have some clues.

[cajunjoel]

Followup: I removed and reinstalled librephotos in my unRAID and after leaving it for a good 12 hours, it showed this:

IMAGE ID [2052977936]: Pulling from reallibrephotos/singleton.
IMAGE ID [2b55860d4c66]: Pulling fs layer. Downloading 100% of 29 MB. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [c9531d902462]: Pulling fs layer. Downloading 100% of 59 MB. Download complete. Extracting. Pull complete.
IMAGE ID [be66bca1ea1f]: Pulling fs layer. Downloading 100% of 982 KB. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [4663dc8e1f6b]: Pulling fs layer. Downloading 100% of 53 KB. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [a5dad0205331]: Pulling fs layer. Downloading 100% of 106 KB. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [19c79ce54c1e]: Pulling fs layer. Downloading 100% of 67 KB. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [4f4fb700ef54]: Pulling fs layer. Downloading 100% of 32 B. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [fa5a06305772]: Pulling fs layer. Downloading 100% of 4 GB. Verifying Checksum. Download complete. Extracting.
IMAGE ID [553a19e1e159]: Pulling fs layer. Downloading 100% of 845 KB. Verifying Checksum. Download complete.
IMAGE ID [7cc158e7ab15]: Pulling fs layer. Downloading 100% of 1 MB. Verifying Checksum. Download complete.
IMAGE ID [ca63435543ee]: Pulling fs layer. Downloading 100% of 122 B. Verifying Checksum. Download complete.
IMAGE ID [a989e11eb6ef]: Pulling fs layer. Downloading 100% of 5 KB. Download complete.
IMAGE ID [eaab85926d11]: Pulling fs layer. Verifying Checksum. Download complete.
IMAGE ID [11fd8a697ba9]: Pulling fs layer. Downloading 100% of 5 KB. Verifying Checksum.
IMAGE ID [ea525780ae72]: Pulling fs layer. Downloading 100% of 174 B. Verifying Checksum. Download complete. 

According to this, it never finished installing. And even though I told it not to start, it was running with the same error reported at the top of this ticket.

[bighill2000]

I got it to work for me by doing the following:

1. Fresh install - wait for it to finish
2. Login into console for the docker
3. Run /bin/bash
4. Should be in directory /librephotos-linux - If not run cd /librephotos-linux
5. Run the install script - ./install-librephotos.sh

After doing that all of my errors are gone and it picks up all the pictures in my photos folder.

[derneuere]

The install-script is not used on startup. We only use it for building the image. Most issues seem to be that the database does not start up fast enough for the backend. If you have an idea, you should look into this instead.

[cajunjoel]

I am commenting months later on this ticket because it's still ongoing and I have run out of patience beating my head up againast it. I've restarted my docker container a dozen times and every time I get the plethora of errors.

I did what @bighill2000 said above and that completely failed with If librephotos-backend not starting, try to uninstall vips and recompile again

Why is it so hard to create the database tables? Isn't it easy to check if they do exist and create them if they don't?

is there some other script I can call from the console? I want to use Librephotos, I want to like it, but this is bordering on the ridiculous. (I also tried installing in a VM and that also failed for approximately the same reasons)

[derneuere]

@cajunjoel If you want to look into this, the code for that is here: https://github.com/LibrePhotos/librephotos-linux

This repository installs the components of LibrePhotos as systemd services:

• systemd does not work reliably within a docker container, we use a replacement script from here
• to check if there is a database or not, we use the docker-entrypoint.sh script from the official repository

The general idea is that the installation script gets called on build time and the entrypoint.sh get called when you start the actual container.

I hope it helps you find your issues a bit quicker. Looking forward to your pull requests :)

[Allesanddro]

Same problem

also occurs if I use this guide https://docs.librephotos.com/1/manual_debian_install/

[xLorak]

Had the same issue on recent version of Unraid
my solution was change paths to librephotos directories mounted in shares to /mnt/cache/appdata/xxxxxxx
add Variable FIXPERMISSIONS with true default value, also localy i have this docker on custom ip port, and working with photos trough http 80 port instead of 3000, this one is only for outside mapping in router settings
After that at first lucky attempts of logging to www interface, hit scan all library again.

[josiah-roberts]

+1, same issue. It seems that there's some issue with the singleton docker image; behavior on Unraid vs. other Docker hosts should be agnostic. Specifically, migrations aren't being (successfully) run.

[josiah-roberts]

Confirmed that the same issue occurs outside of Unraid when just using the singleton image directly on a local docker setup.

[iball]

Same issue here. First time I've ever run in a real problem with a Docker container on UNRAID that couldn't be quickly resolved.
Running that .sh script just creates a 504 nginx error now.
Is there another image for UNRAID that actually works?

[stephenpapierski]

Are there any additional setup steps required for the Unraid container (anything with .env or additional parameters)? Mine installs and starts up fine, but does not take me to the initial setup page. I get the following errors.

Internal Server Error: /api/firsttimesetup/
Traceback (most recent call last):
  File "/usr/lib/librephotos/.local/lib/python3.10/site-packages/django/contrib/sessions/backends/base.py", line 187, in _get_session
    return self._session_cache
AttributeError: 'SessionStore' object has no attribute '_session_cache'

psycopg.OperationalError: connection failed: Connection refused
        Is the server running on that host and accepting TCP/IP connections?
connection to server at "localhost" (::1), port 5432 failed: Cannot assign requested address
        Is the server running on that host and accepting TCP/IP connections?

Is the database internal to the container, or do I need to be pointing it at a postgres db?

Also, it looks like the singleton docker image that this is based on hasn't been updated in 6 months. Should we be pointing elsewhere for this? I'm willing to do some work on this, just trying to understand the scope of the problem.

[stephenpapierski]

Based on the docker-compose, it looks like you need the librephotos-proxy, postgres, librephotos-frontend, and librephotos containers for it all to work. @derneuere is the singleton container still active? Or should us Unraid users plan to find a different path forward (such as docker-compose)?

[derneuere]

The singleton container does not get any updates at the moment.

The issues are twofold:

1. It is based on the local install method, which is flawed in it's architecture, as updating needs technical expertise. I assumed that linux users know what they are doing and would provide improvements over time. That assumption was wrong. The downstream effect are lot of answering technical questions. This is bad as I am a bottleneck anyway in this project and my time should be better spend at fixing bugs or adding features.
2. The local install method also uses systemd, which is a bad idea to run in a container. I added a python replacement script to override these call, but it looks like the project should switch to something else instead.

I did not officially sunset it yet, as I want to provide a clear path forward, to implement both off these options again. Sadly, I did not find the time to research all of the options yet.

The current image still does work for some users, while others report this issue here, which I could not reproduce.

[stephenpapierski]

Thanks for the update! I went ahead and pursued docker compose only to run into a database error there as well. Enabling hard links on Unraid got me past that issue and ended up allowing the singleton image based app to work as well. Fair warning it messed some other things up, and I've since reverted. So only do that if you know what you're doing. But it might explain why it works for some and not others.