Version 1.0.0-alpha.3 and 1.0.0-alpha.4 is out!

Changes in this build:

Installation instructions are here: V1.0.0-alpha.1 is out! Alpha testers: assemble

Join us on discord!

Docker users, please read

This version introduces running as a custom UID/GID .

Unless you’ve been using --user and a userns map, your files are probably owned by root, and not the user you want to run PhotoStructure as.

Pick a user to run PhotoStructure as, and chown -R the bind mounted files, including

  • /ps/library/.photostructure
  • /ps/config/*
  • /ps/cache/*
  • /ps/log/*

Don’t skip any of them!


Getting this scary docker error which happens immediately when either:

  • I run the container using Synology docker UI
  • using docker run photostructure/server:alpha in ssh

Start container photostructure-v1alpha3 failed: {“message”:“OCI runtime create failed: container_linux.go:345: starting container process caused “exec: \”/ps/\”: stat /ps/ no such file or directory": unknown"}.

Also broken on my unraid docker.

It upgraded fine, but won’t start. I get the message “Execution Error, bad parameter.”

I get the same error (using docker-compose).

This should probably be /ps/app/ instead.

For plain docker, you could probably try docker run --entrypoint /ps/app/ photostructure/server:alpha if you want to test it before Matthew fixes the image.

1 Like

Thanks! I’m rebuilding the image right now.


Update: the entrypoint script needed +x, and it seems like the chmod call is a Bad Idea (it takes forever: and the usermod should take care of it already).


Let us know when you push the new image to dockerhub!


It’s pushing now. Here’s what changed:

1 Like

Again, apologies @Adrian-Ng and everyone else for that rough release…


It’s an alpha. That’s what it’s for. :slight_smile:

But now I"m getting:
Error: code ENOENT: ENOENT: no such file or directory, open '/ps/config/PhotoStructure/settings.toml' Error: ENOENT: no such file or directory, open '/ps/config/PhotoStructure/settings.toml' {"fatal":true,"exit":true,"status":14,"pid":22,"ppid":15,"error":"main setup failed: Error: code ENOENT: ENOENT: no such file or directory,open '/ps/config/PhotoStructure/settings.toml'¹"} 2021-04-11T21:03:37.156Z main-22 error Caught error from file write stream Error: EACCES: permission denied, open '/ps/logs/2021-04-11/main-22-001.log'

1 Like

The word of the day is more than comfortably appropriate

1 Like

@Wooskey I just added these instructions to the top of the topic. Sorry for the hassle…

So I’m basically forcing people to run PhotoStructure as a non-root user in this version.

  1. Should I not? Is that a Bad Idea?

  2. Should I let people run as root? That means all the files that PhotoStructure produces are owned by root, which is decidedly not ideal.

As an end-user, not a coder, I’d guess that its smart to not run PS as root.

I don’t know if this is relevant, but a personal pet-peeve of mine is when mapped paths are not accessible when I share those paths from the host via SMB. I have not yet had that problem with Photostructure, and I would be a little annoyed (just a little, not a lot) if that changed.

OK: here’s the next build’s entrypoint script. If you don’t read shell, here’s the TL;DR:

  • If you set --env UID=0, PhotoStructure will behave as it did in prior versions, and run and write all files as root.

  • If you set --env PS_FIX_PERMISSIONS=1 UID=1234 GID=2345 (where 1234 is the user id you want PhotoStructure to run as, and 2345 as the group id), docker will chown --recursive $UID:$GID /ps/*, which should fix all permission issues of running previous builds as root.


# Tell PhotoStructure we're running under docker:
export PS_IS_DOCKER="1"

# Node is installed in /usr/local/bin:
export PATH="${PATH}:/usr/local/bin"

# Are we already not root, or are they forcing PhotoStructure to run as root?
if [ "$UID" = "0" ] || [ "$(id --real --user)" != "0" ]; then
  # They want to run as root or started docker with --user, so we shouldn't do
  # any usermod/groupmod/su shenanigans:
  /usr/local/bin/node /ps/app/photostructure "$@"
  # Accept either UID or PUID:
  export UID=${UID:-${PUID:-1000}}
  # Accept either GID or PGID:
  export GID=${GID:-${PGID:-1000}}

  # Change the phstr user and group to match UID/GID.
  # (we don't care about "usermod: no changes"):
  usermod --non-unique --uid "$UID" phstr | grep -v "usermod: no changes"
  groupmod --non-unique --gid "$GID" phstr
  # Make sure the settings, opened-by, and models directories are writable by phstr:
  chown --recursive phstr:phstr /ps/library/.photostructure/settings.toml /ps/library/.photostructure/opened-by /ps/library/.photostructure/models

  # Help for prior users that ran as root:
  if [ "$PS_FIX_PERMISSIONS" = "1" ]; then
    echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
    echo "!!! recursively changing file ownership in all /ps/* volumes !!!"
    echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
    echo "Hit ctrl-c in the next 10 seconds to cancel running the following:"
    echo "# chown --recursive $UID:$GID /ps/*"
    sleep 10s
    chown --recursive $UID:$GID /ps

  # - `exec tini` to prevent zombies
  # - Start photostructure as user phstr instead of root:
  su --preserve-environment phstr --command "/usr/local/bin/node /ps/app/photostructure $*"
1 Like

I’m having no luck.

I ended up just blowing away the docker and the settings and starting from scratch.

Now it starts fine. However, the initial start screen does not load properly. Then the screen to select the free or paid plan works fine. Then if I select free the configure screen does not load properly. None of the graphics load. And this is a fresh install.


What OS is running your container? Can you dm me a screenshot or send me logfiles of what you’re seeing? Thanks!

Download link PhotoStructure | Install PhotoStructure for Desktops gives PhotoStructure-Installer-1.0.0-alpha.3.exe rather than alpha.4

I’m still getting “PS_LIBRARY_PATH, /ps/library, doesn’t exist: please add it as a bind mount.” I have added both UID and GID = 0 to no effect. The path is mounted, although when I cd to the path within the container, I do not see any files.

Alpha.4 only had a couple changes related to docker, so I didn’t rebuild the desktop images again.

Today’s build that fixes a couple more issues that were found yesterday will also include the desktop images.

1 Like

Apologies! I’ll get that fixed today.