Hey friends!
I’m still on /e/OS 1.9 (I know, I know…), and the latest version of the server software.
My photos aren’t syncing. Even when I attempt to force a sync, it doesn’t seem to want to do it.
My contacts and calendar appointments, however, sync just fine.
Open to suggestions! =)
Regain your privacy! Adopt /e/OS the deGoogled mobile OS and online services
Well, I solved it! …sort of.
Still unsure why photos aren’t syncing with the regular /e/Cloud server…but what I’ve learned thus far is that a good amount of what I’d like to do can be performed by appending it! Here’s my tutorial for implementing Immich, a self-hosted photo management app. It also includes some AI stuff that does facial recognition and a few other things, so it’s a bit more robust than standard Nextcloud photo syncing. Also, be aware that, especially during the initial upload and cataloguing, it will peg that CPU needle at 100% for quite a while…so if you’re paying by the CPU cycle…read the documentation to avoid the use of its photo analysis.
Here’s my tutorial:
nano /mnt/repo-base/config/letsencrypt/autorenew/ssl-domains.datdocker stop nginxcd /mnt/repo-base/scripts && ./ssl-renew.shnano `/mnt/repo-base/.env and append it with these environment variables:#immich: a friendly comment to help isolate issues later (documentation is a love letter you write to your future self).UPLOAD_LOCATION=/mnt/immich/library a folder where photos go; be sure it exists.DB_DATA_LOCATION=/mnt/immich/db a folder where the database goes; be sure it exists.TZ=UTC your time zone; this is helpful for finding photos later.IMMICH_VERSION=release …I’m assuming there are other releases, but I’m not crazy, so ‘release’ it isDB_PASSWORD=omgwtfbbqchangeme12345 Database Password; make your own, this isn’t mine.DB_USERNAME=postgres default; no real reason to change itDB_DATABASE_NAME=immich default; no real reason to change it.nano /etc/repo-base/docker-compose.yml; append the file with the docker-compose section below.cd /mnt/repo-base && docker-compose up -d ; let it do its magic. nano /mnt/repo-base/config/nginx/sites-enabled/photos.voyager529.com.conf, and add the nginx config section below (please read the comments)docker restart nginx ; test on your phone to see that you can access the website.Now, download the app on your phone, point it to your instance, and you can let it handle your photo uploads!
Two things to note before I get to the files:
First, I removed all the GPU acceleration options from the software; I might be the weirdo who self-hosts on actual hardware instead of a VPS, but I would be fairly surprised if anyone is running this somewhere that’s got a GPU and would benefit from its use here. If you want to add it, you can, but go consult the Immich documentation regarding the process (it’s just a few extra lines in the docker-compose).
Second, my particular version of docker didn’t like Immich’s health check intervals, so I removed them as some other forum posters did. It may take them a bit to show up as ‘healthy’ as a result, but it’s purely cosmetic, which is why they’re not present here.
Without further ado…
the docker-compose file for Step 5 (again, ADD to the bottom of your EXISTING docker-compose.yml)
name: immich
services:
immich-server:
container_name: immich_server
image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
volumes:
- ${UPLOAD_LOCATION}:/usr/src/app/upload
- /etc/localtime:/etc/localtime:ro
env_file:
- .env
ports:
- 2283:3001
depends_on:
- redis
- database
restart: always
immich-machine-learning:
container_name: immich_machine_learning
image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
volumes:
- model-cache:/cache
env_file:
- .env
restart: always
redis:
container_name: immich_redis
image: docker.io/redis:6.2-alpine@sha256:328fe6a5822256d065debb36617a8169dbfbd77b797c525288e465f56c1d392b
healthcheck:
test: redis-cli ping || exit 1
restart: always
database:
container_name: immich_postgres
image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
environment:
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_USER: ${DB_USERNAME}
POSTGRES_DB: ${DB_DATABASE_NAME}
POSTGRES_INITDB_ARGS: '--data-checksums'
volumes:
- ${DB_DATA_LOCATION}:/var/lib/postgresql/data
healthcheck:
test: pg_isready --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' || exit 1; Chksum="$$(psql --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' --tuples-only --no-align --command='S>
# interval: 5m
# start_interval: 30s
# start_period: 5m
command: ["postgres", "-c" ,"shared_preload_libraries=vectors.so", "-c", 'search_path="$$user", public, vectors', "-c", "logging_collector=on", "-c", "max_wal_size=2GB", "-c", "shared_buffers=512MB", ">
restart: always
volumes:
model-cache:
And, the nginx config from step 8:
server {
listen 8000; #YES THIS IS THE CORRECT PORT
server_name photos.voyager529.com;
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 4430 ssl http2; #YES THIS IS THE CORRECT PORT
server_name photos.voyager529.com;
#replace these if you're using commercial certs
ssl_certificate /certs/live/photos.voyager529.com/fullchain.pem;
ssl_certificate_key /certs/live/photos.voyager529.com/privkey.pem;
include /etc/nginx/params/ssl_params;
include /etc/nginx/params/headers_params;
client_max_body_size 50000M; #from Immich documentation; make smaller if needed
# Set headers
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# enable websockets: http://nginx.org/en/docs/http/websocket.html
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_redirect off;
# set timeout
proxy_read_timeout 600s;
proxy_send_timeout 600s;
send_timeout 600s;
location / {
proxy_pass http://immich_server:3001; #YES THIS IS THE CORRECT PORT
}
}
Hope it helps someone else who’s either having issues with photo syncing, or prefers some of Immich’s more robust features!
@smu44, always up for your input…and @manoj , feel free to edit the original post with how-to tags if it’d be helpful.
Nice one @voyager529! 
My 2 cents:
){Edit] You may adjust depends in Docker Compose immich-server, to immich_redis and immich_postgres
Thank you so much, kind sir! …if you happen to have any insight on why /e/Cloud isn’t doing the thing, I’d love to have two sets of solutions here =).
I’m lazy and am letting XSI Backup handle that until I finally make the cutover to Proxmox and let PBS handle it 
My first draft of this procedure list actually was written the way you describe! I was just a bit nervous about having the initial setup window being publicly accessible…so I thought that I’d make the procedure list so that the initial setup would be performed over the LAN to avoid someone replying and telling me “zomg don’t have the initial config publicly accessible!”…you just can’t win on the internet
So, there were a few reasons for this logic. The 2283:3001 is how the docker compose file from Immich is implemented, so I didn’t want to alter the docker-compose file any more than I had to. Similarly, If a user were to have issues, the Immich documentation refers to that port structure, so I wanted to keep it in order to ensure that the Immich documentation still applies.
Forgive me if I’m misunderstanding the second half, but my understanding with regards to /e/Cloud, simply put, is that 8000 is the port that nginx listens on for anything other than autodiscover; the same for 4430 for https…I mean, I know it’s a bit more complex than that, but so far I’ve had success with “listen on 8000/4430 and ‘location’ your way to the internal port”…I’m open to learning how to streamline a bit better =).
I did not! …mostly because my understanding is somewhat limited here, and one of the things I was concerned about was an issue with Immich impacting /e/Cloud. Now, it looks like Redis is basically an in-memory database cache/accelerator, so the odds of me causing data loss is more limited than if they were sharing an actual database, but between that, the desire to keep Immich’s instructions as close to the official documentation as possible, and my limited understanding…I have redundant instances here.
For what it’s worth, my instance is using a little over 4GB of RAM with /e/Cloud, Librey, and Immich all active on the server. More to the point, Immich itself is the resource hog here, with over 3GB of RAM used just for the immich-server container. On a tangentially related point…since the Redis instance from /e/Cloud is caching MariaDB, would it even be able to simultaneously cache queries from the Postgres database that powers Immich?
It’s often related to Android MediaProvider, and eDrive app own database and behaviour … Difficult to debug, indeed 
It’s okay-ish, don’t forget that a snapshot or raw backup of a running database is unlikely to be usable after a restore. However, PostgreSQL have stronger repair mechanisms than MariaDB.
I got your point, but VPS owners (99% of the time text-only instances) can’t throw a browser on local addresses (moreover, the only IP address available is often … the public one!).
If you get hacked, at this point no personal data is involved, so just throw away Immich data and start over.
Maybe the setup can be automated from script in any way? Tool lazy to read the doc
That’s okay, it will work this way 
But please note that this will expose 3001 on host IP address, and that might be not be consistent with the idea of hiding services behind a reverse proxy (especially on VPS with a public IP address)…
I was referring to listening on HTTPS/4430 then passing to HTTP/2283, removing the port translation in Docker. Sorry if it wasn’t clear
Some output of a docker stats --no-stream will be of interest here
For /e/Cloud, Redis is also used for RSpamd. My idea was to save some RAM and CPU, but it’s okay to have a separate Redis for Immich!
This topic was automatically closed after 90 days. New replies are no longer allowed.