Fixed: PhotoStructure Docker does not start

Support
1

Expected Behavior

On Synology DSM 7.2, PhotoStructure Docker does not start.

Current Behavior

In the logs I can see this:

date stream content
2023/07/04 10:23:03 stdout at F (/ps/app/bin/main.js:9:193039)
2023/07/04 10:23:03 stdout e[90m at console.warn (node:internal/console/constructor:365:61)e[39m
2023/07/04 10:23:03 stdout e[90m at console.value (node:internal/console/constructor:332:14)e[39m
2023/07/04 10:23:03 stdout e[90m at formatWithOptions (node:internal/util/inspect:2029:10)e[39m
2023/07/04 10:23:03 stdout e[90m at formatWithOptionsInternal (node:internal/util/inspect:2167:40)e[39m
2023/07/04 10:23:03 stdout e[90m at inspect (node:internal/util/inspect:347:10)e[39m
2023/07/04 10:23:03 stdout e[90m at formatValue (node:internal/util/inspect:817:10)e[39m
2023/07/04 10:23:03 stdout e[90m at formatRaw (node:internal/util/inspect:962:14)e[39m
2023/07/04 10:23:03 stdout e[90m at formatError (node:internal/util/inspect:1292:11)e[39m
2023/07/04 10:23:03 stdout e[90m at improveStack (node:internal/util/inspect:1253:20)e[39m
2023/07/04 10:23:03 stdout onError() failed⁹ RangeError: Maximum call stack size exceeded

Steps to Reproduce

  1. Just download the last docker version
  2. And start…

Environment

Operating system and version:
Synology DSM 7.2
PhotoStructure edition:
PhotoStructure for Docker

2

Also, Docker version of PhotoStructure is too old : 1 year.

3

Can you share your exact setup for the docker container?

Alpha 7 (v2.1.0-alpha.7) is the most recent version, so that is correct. The new alpha is in development and will be released soon!

4

{
“CapAdd” : ,
“CapDrop” : ,
“cmd” : “”,
“cpu_priority” : 90,
“enable_publish_all_ports” : false,
“enable_restart_policy” : true,
“enable_service_portal” : null,
“enabled” : false,
“env_variables” : [
{
“key” : “PATH”,
“value” : “/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”
},
{
“key” : “NODE_VERSION”,
“value” : “16.16.0”
},
{
“key” : “YARN_VERSION”,
“value” : “1.22.19”
},
{
“key” : “PS_IS_DOCKER”,
“value” : “true”
},
{
“key” : “NODE_ENV”,
“value” : “production”
},
{
“key” : “PGID”,
“value” : “0”
},
{
“key” : “PUID”,
“value” : “0”
},
{
“key” : “PS_LIBRARY_PATH”,
“value” : “/photo”
}
],
“exporting” : false,
“id” : “46892dc978cc2bbc5551b5e73e905f519a57ca0e7e984c0e211627fe7679f1f5”,
“image” : “photostructure/server:latest”,
“is_ddsm” : false,
“is_package” : false,
“labels” : {},
“links” : ,
“memory_limit” : 34359738368,
“name” : “photostructure”,
“network” : [
{
“driver” : “bridge”,
“name” : “bridge”
}
],
“network_mode” : “bridge”,
“port_bindings” : [
{
“container_port” : 1787,
“host_port” : 1787,
“type” : “tcp”
}
],
“privileged” : true,
“service_portals” : ,
“shortcut” : {
“enable_shortcut” : false,
“enable_status_page” : false,
“enable_web_page” : false,
“web_page_url” : “”
},
“use_host_network” : false,
“version” : 2,
“volume_bindings” : [
{
“host_volume_file” : “/docker/volumes/photostructure/logs”,
“is_directory” : true,
“mount_point” : “/ps/logs”,
“type” : “rw”
},
{
“host_volume_file” : “/docker/volumes/photostructure/config”,
“is_directory” : true,
“mount_point” : “/ps/config”,
“type” : “rw”
},
{
“host_volume_file” : “/docker/volumes/photostructure/tmp”,
“is_directory” : true,
“mount_point” : “/ps/tmp”,
“type” : “rw”
},
{
“host_volume_file” : “/docker/volumes/photostructure/library”,
“is_directory” : true,
“mount_point” : “/ps/library”,
“type” : “rw”
},
{
“host_volume_file” : “/photo”,
“is_directory” : true,
“mount_point” : “/photo”,
“type” : “rw”
}
]
}

5

Have you seen this thread? Maybe there’s something there that can help you?

@nuk do you see what the problem might be?

6

Yes.
Nothing works.
Photostructure needs to update docker image.
I am migrating from DSM 6 to DSM 7 to another NAS, and I am consider to use other options like photoprism.
Photostructure support is very poor.
Regards,
Jordi
JOINSO

1 Like
7

Sorry you feel that way. Photostructure is a young software that is being developed by a single developer. Many of us users here find @mrm to provide excellent support, often going out of his way to help us get things going.

Hopefully you can appreciate that making a software available on many different platforms via Docker, while amazing, can cause support problems when the developer (or the user base) doesn’t have extensive knowledge on your host platform of choice. In those instances, it’s hard to get concrete answers coming from the software side of the equation.

One other option would be for you to reach out in Synology-centric places (forums, discords, subreddits, etc) to see if they have any insight.

I know it’s frustrating when you just want to install software and have it just work™, but unfortunately with Docker it just doesn’t work that way.

If you want to keep trying with Photostructure, we’ll do our best to help you get up and running. But, if you don’t want to keep trying, we understand.

8

I just re-read your config, and there are several issues:

1. Overwriting your library directory

The “library” directory in this case refers to the PhotoStructure library, which may or may not contain your original photos and videos (that’s up to you).

You’re adding bind mounts to /ps/library, which is the default PS_LIBRARY_DIR value, and then you’re telling PhotoStructure to ignore those directories by setting PS_LIBRARY_DIR to /photo.

2. Don’t run as root, if possible:

Another bit I’d recommend: don’t run PhotoStructure as root. Read this to see why.

Instead, add a non-admin user that has at least read and execute permissions to your /photo host directory.

3. Is /photo a directory on your host machine?

If you ssh into your host machine, is /photo the actual path to your photo volume? I’d be less suspicious if it was something like /volume1/homes/photos, at least on a Synology. My NAS has no “friendly” volume links from the root directory, for what it’s worth, but yours may be different.

Final config

You should be able to

  1. remove all the other env variables other than PGID and PUID
  2. only bind-mount something for /ps/library and /photos

Something like this:

{
  “env_variables”:
    [
      { “key”: “PGID”, “value”: “0” },
      { “key”: “PUID”, “value”: “0” },
    ],
  “image”: “photostructure/server:alpha",
  “name”: “photostructure”,
  “network”: [{ “driver”: “bridge”, “name”: “bridge” }],
  “network_mode”: “bridge”,
  “port_bindings”:
    [{ “container_port”: 1787, “host_port”: 1787, “type”: “tcp” }],
  “privileged”: true,
  “volume_bindings”:
    [
      {
        “host_volume_file”: “/docker/volumes/photostructure/library”,
        “is_directory”: true,
        “mount_point”: “/ps/library”,
        “type”: “rw”,
      },
      {
        “host_volume_file”: “/photo”,
        “is_directory”: true,
        “mount_point”: “/photo”,
        “type”: “rw”,
      },
    ],
}
9

Here is the real setup in Synology:

image
image970×473 31.6 KB

So, the setup of volumes is what you say.

The problem is the memory issue: stack excedeed.

Regars,
Jordi
JOINSO

10

Did you remove the extraneous environment variables and restart?

11

Just to distill @mrm 's suggestion:

  • Get rid of all environment variables except PGID and PUID
  • change the repository to photostructure/server:alpha
  • Get rid of all bind mounts except for /ps/library and /photo

If you try that and then still get the Maximum call stack size exceeded then there is something else going on.

12

Oh! @JOINSO have you seen this?

He did it with DSM7, and has details for how to run 2 libraries in parallel on the same computer. He has a ton of tips and good screenshots.

Sometimes just seeing something explained in a different way will make things click.

13

Yes.
And it fails with a different error:

date stream content
2023/07/05 10:17:01 stdout ]
2023/07/05 10:17:01 stdout e[32m’_ (/ps/app/bin/main.js:9:449259)'e[39m
2023/07/05 10:17:01 stdout e[32m’u (/ps/app/bin/main.js:9:780699)'e[39m,
2023/07/05 10:17:01 stdout e[32m’/ps/app/bin/main.js:9:188157’e[39m,
2023/07/05 10:17:01 stdout e[32m’t.systemSettingsFile (/ps/app/bin/main.js:9:632393)'e[39m,
2023/07/05 10:17:01 stdout e[32m’u (/ps/app/bin/main.js:9:780699)'e[39m,
2023/07/05 10:17:01 stdout e[32m’/ps/app/bin/main.js:9:183061’e[39m,
2023/07/05 10:17:01 stdout e[32m’t.desktopConfigDir (/ps/app/bin/main.js:9:189722)'e[39m,
2023/07/05 10:17:01 stdout e[32m’t.firstDirOrFail (/ps/app/bin/main.js:9:183575)'e[39m,
2023/07/05 10:17:01 stdout [
2023/07/05 10:16:59 stdout ]

Regards,
Jordi
JOINSO

14

I will take a look tomorrow.
Regards,
Jordi
JOINSO

15

Hi!
Now it works.
The secret was using the alpha version.
Regards,
Jordi
JOINSO

16

I have a final question.
In my old NAS, I use watchtower to keep using the last version of docker images.
What it is going to happen if I apply to PhotoStructure?
Is going to update to “latest” instead of alpha?

Regards,
Jordi
JOINSO

17

Watchtower will update to the newest image that satisfies the image constraint–so if you say photostructure/server:alpha, it will stay on v2.1.0-alpha.7 until I push a new alpha build.

If you want watchtower to not upgrade your container, simply remove the watchtower reference in your docker-compose.

You can also replace :alpha with the specific version number. Every build is tagged with their version.

Also: know that PhotoStructure :alpha, :beta, and :stable tags are managed such that they always point to the “best” version for that tag–so when there’s a :beta or :stable build that is newer than the latest :alpha build, the :alpha tag will point to that build.

This was requested by several PhotoStructure users so that

  • :alpha means “the most recent build that is alpha, beta, or stable”.
  • :beta means “the most recent build that is beta or stable”.
18

Unfortunately my system is offline for several weeks due to moving and upcoming work deadline. I intend to fully document my preferred setup, but first intend to:

  1. Get wired ethernet into my new office for the NAS, as it doesn’t have wifi and wired is better anyway for a NAS
  2. Update from DSM 7.1 to 7.2 and figure out whether I want to use the totally new method for docker containers or not
  3. Wait until @mrm releases a new stable version (or at least stable for docker). I’ve played enough to know the bugs for me in current version, and I’m not currently interested in reinstalling the same thing yet again.

Matt said in discord that next alpha version should be considered unstable for all platforms unless you have good backups, which is also on my to do list.

My guess is at least a month until another stable-for-docker version comes out (whether it’s still labeled as alpha or not), and hopefully I’ve resolved the other items by then.