Can't join network when deploying via Portainer

I deployed the stable version using docker compose within portainer. The stack deployed fine and the container reports healthy, but it won’t stay on the docker network; keeps disconnecting. Watchtower keeps it’s ip address but photostructure won’t. As a result, I can’t access the web page of photostructure itself. I used the example docker compose fie and changed the requisite code references to match my environment (for bind-mounts).

Here is the docker compose file I used:

version: "3.7"
services:

  photostructure:
    image: photostructure/server:stable
    container_name: photostructure
    restart: unless-stopped
    stop_grace_period: 2m

  volumes:
    - type: bind
      source: /home/<user>/photostructure
      target: /ps/library
    - type: bind
      source: "/tmp/ps-<user>"
      target: /ps/tmp
    - type: bind
      source: "/home/<user>/photostructure/config"
      target: /ps/config
    - type: bind
      source: "/home/<user>/photostructure/config/logs"
      target: /ps/logs

  ports:
    - 1787:1787/tcp
    
  environment:
    - "PUID=1000"
    - "PGID=1000"
    
  labels:
    - "com.centurylinklabs.watchtower.enable=true"
    
  watchtower:
    image: containrrr/watchtower
    restart: always
    container_name: watchtower

  volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - 
  command: --interval 10800

  environment:
    - "WATCHTOWER_LABEL_ENABLE=true"

Thoughts?

Howdy @PanavisionT16 , welcome to PhotoStructure!

I’d try the :beta label, and also enable logging to see what’s going on.

  photostructure:
    image: photostructure/server:beta
...
  environment:
     - "PS_LOG_LEVEL=debug"

The beta build hopefully will just redirect you to the new health check page and point to what’s going awry.

In case you missed it, here are the docker-compose docs: PhotoStructure | PhotoStructure for Docker Compose

The v2024 builds only require a single /ps/library mount point if it’s a local disk, and a /ps/cache mount point if your /ps/library is a remote mount.

Does the console log of the container show anything interesting? If everything starts ok it should show something like this. Anything else, not so much.

ps  | PhotoStructure is ready:
ps  |   - http://127.0.0.1:1787/
ps  |   - http://172.19.0.7:1787/
ps  |   - http://photostructure:1787/

I also noticed you have “restart: unless-stopped” in your docker compose, which is the right “normal” setting but may be masking a boot failure loop. Maybe temporarily remove that line.

Error: EACCES: permission denied, open ‘/ps/config/settings.toml’

Error: code EACCES: EACCES: permission denied, open ‘/ps/config/settings.toml’

Error: EACCES: permission denied, open ‘/ps/config/settings.toml’

fatal=true exit=true status=14 pid=25 ppid=18 error=main setup failed: Error: code EACCES: EACCES: permission denied, open '/ps/config/settings.toml’¹

This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:

Error: EACCES: permission denied, open ‘/ps/config/settings.toml’

This is due to /ps/config not being owned or writable by your PUID/PGID. chmod that directory to your user and chmod u+rwX.

Your docker compose bind mounts aren’t literally /home/<user>, correct?

Did you switch to the beta label?

lol, no, I swapped out the real username with user (but we all know what it refers to).

This was meant to be a simple test deployment so I could see how the program works. I have a large DAS array that holds all my photos and is controlled by a windows file server so I will need to eventually mount the shared drive via SMB so photostructure can access it. Would it behoove me to join the photostructure host to my Active Directory domain to make things easier in that regard?

1 Like

As I’m sure you’re aware, POSIX user IDs and group IDs aren’t a thing (as far as I know!) under windows. If this is all running under Windows, you may need to set PUID/PGID to 0 to run root, as samba (again, as far as I know) can only masquerade an SMB mount as a single user ID (and all bets are off if you’re just mounting a windows share to another windows share: you’ll want to skip all docker and POSIX permissions).

Well, the setup I have is an R740 with 20 cores, 511GB RAM with an attached 60TB DAS RAID5 Array. I’m running vmware esxi 7.0. Portainer is a standalone deployment that manages all the docker deployments (either separate standalone ubuntu vm’s or a cluster). I dedicated an ubuntu 24.04.01 LTS server for photostructure and gave it 8 cores, 16GB RAM and plenty of HD space from the array to handle the eventual library. I’m thinking the PUID change to 0 for root will solve the issue. Should I change the user to root as well or leave it to the login admin?

changing the user to root (0) is kind of the nuclear option… If that doesn’t work…

  1. There have been docker exploits that allowed for either exfiltration of data from the host, or outright shells, when the docker container’s code is running as root. While I’ve written PhotoStructure to be as well-mannered and polite as it can, in general, root processes should be avoided whenever possible.
  2. All files created by PhotoStructure (in your cache and library) will be owned by root. This’ll be a PITA if you have to chown everything back to your role user.

We’re looking at a file permission issue. Can you bind-mount that same directory to a simple Alpine or Ubuntu docker image and touch a file with userid 1000?

Also, in case the uid/gid is somehow muddled: if you just touch /ps/config/settings.toml with the userid and groupid you want PhotoStructure to run as, you can skip the PUID/PGID setting–my bootstrap script will automatically set the PUID and PGID to match that.