Newly here; hoping for some pointers on getting PS working in Docker on a Pi4. I’m pretty sure it’s failing because of architecture mismatch. Is the alpha image multiarch? Do I have to built it myself?
Thanks much
Welcome to PhotoStructure @115 !
The latest :alpha docker build is multiarch. Raspberry Pi-specific installation details are here:
Thanks for the welcome. I have been round and round the documentation, which is great by the way. That Pi page is useful but mainly focuses on the compromises that the limited processor brings. I followed the links to Docker installs and then the details for Docker Compose.
My first mistake was to try ‘latest’; and so was getting architecture errors.
Now I’m loading ‘alpha’ my docker log is this below.
I just don’t know enough to know where to start try to fix, so grateful for any tips
Container started
25/01/2023 18:35:04
Error: Error loading shared library ld-linux-aarch64.so.1: No such file or directory (needed by /ps/app/node_modules/utimes/lib/binding/napi-v3/utimes.node)
25/01/2023 18:35:04
at Object.Module._extensions..node (node:internal/modules/cjs/loader:1189:18)
25/01/2023 18:35:04
at Module.load (node:internal/modules/cjs/loader:981:32)
25/01/2023 18:35:04
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
25/01/2023 18:35:04
at Module.require (node:internal/modules/cjs/loader:1005:19)
25/01/2023 18:35:04
at require (node:internal/modules/cjs/helpers:102:18)
25/01/2023 18:35:04
at /ps/app/node_modules/utimes/src/main.ts:18:9
25/01/2023 18:35:04
at Object.<anonymous> (/ps/app/node_modules/utimes/src/main.ts:19:3)
25/01/2023 18:35:04
at Module._compile (node:internal/modules/cjs/loader:1105:14)
25/01/2023 18:35:04
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
25/01/2023 18:35:04
at Module.load (node:internal/modules/cjs/loader:981:32)
Thank you!!
Oof, that looks like the utimes module that PhotoStructure is dependent on isn’t compiled against the correct environment. I’ll try to reproduce that on my pi right now and see how to fix it in the next build.
In the meanwhile, instead of using docker, I’d suggest running PhotoStructure for Node, which will compile everything specific to your pi.
Thanks for your help; I’ll watch the release notes every few months. Great looking site and app.
Hi Matthew - thank you for creating PhotoStructure! I’m starting in on trying to make a collection of a few tens of thousands of photos more accessible for my family.
I’ve run into this same issue, on a Synology DS223. Looks like this NAS uses a Realtek CPU, which I think is an ARM processor.
The solution I’m working towards is spending an extra $50 or so on a Synology DS224+, which uses an Intel Celeron processor and (hopefully) should run PhotoStructure on Docker just fine. If that’s successful, it might be worth a note in the FAQ / install guide…
Welcome to PhotoStructure, @reed! Apologies for the glitch.
The new alpha build, v2023.12 (that I’m currently releasing right now, it should be available in 30 minutes) actually removes the native library, utimes, from the build, so that should address this issue.
More details about this release are here: PhotoStructure | 2023 PhotoStructure release notes
That’s lucky timing for me! Thank you - confirmed, the installation of 2023.12.0-alpha.3 worked great.
I now have a file permissions issue to chase down: “Please check directory permissions for /ps/library: it must be read/write/execute by user photostructure (userid 1026)” If you have any suggestions, I’m all ears! Screenshot of Synology mapping below, showing that the Docker container should have read/write access.
Note that PhotoStructure for Docker needs correct PUID and PGID values: see https://photostructure.com/server/photostructure-for-docker/#running-photostructure-for-docker-as-a-non-root-user for more details–I suspect your library is not owned by uid 1026. I’ll add who actually owns the library to the health check message right now.
One nasty bit about Synology’s UI is that they seem to hide the user id (at least I couldn’t find it!)–I had to ssh into my NAS as the user that owns my photos, and run id to find the value to set PUID and PGID to.
Thank you. I also found the tips here. I created a new user “photostructure” - got some info from Synology via SSH:
uid=1027(photostructure) gid=100(users) groups=100(users),65536(docker)
Setting environment variables for PUID and PGUID for a bunch of combinations (that user, 1026 which is user “reed”, GID vs Docker GID, using 0 to try and use root) - but haven’t yet been successful…
Huh, I’ve only used PUID+GUID before, and that works for me. But now I have no idea where I would have found GUID. Must have changed with a recent PhotoStructure update, or Synology Container Manager needs a different name, or something else weird?
The numbers you want are 1027 and 100 based on your SSH output.
I noticed I’d inadvertently put “PGID” rather than “GUID” - but nevertheless, every combination of IDs I’ve tried hasn’t worked. I did see an error change, however, when I tried to use PUID = 0
uid=1026(reed) gid=100(users) groups=100(users),101(administrators),65536(docker)
uid=1027(photostructure) gid=100(users) groups=100(users),65536(docker)
Thanks for the guidance & rapid replies, I appreciate it!
-Reed
For future documentation or the next person… The hint I needed was here: https://community.synology.com/enu/forum/1/post/160243
Turned out the problem was due to shared folder restrictions. The shared folder that contained the directory I was trying to map as a volume did not have permissions for
owner.
I noticed another shared folder did work correctly and it did have that permission.
After adding permissions for the owner the file mask was working correctly.
Creating a “photostructure” user didn’t seem to be part of the equation. Once I added myself (reed, UID 1026 in my case) to the Synology shared folder settings, the permissions issue appeared to be resolved.
Glad you got it going! Now that you say that, I think I had a similar issue many moons ago.
So are you running now as root (puid=0), reed (puid=1026), or photostructure (puid=1027)?
Running as “reed”, PUID 1026. I’m not sure what effect creating that “photostructure” user had - it looked to me like PhotoStructure tried to use either root or “reed” but never tried to use “photostructure” even when I’d set PUID=1027.
I think (although I’m not sure) that the “Shared Folder” settings already had read/write set for that “photostructure” user, but the problem was only resolved once I added read/write access for user “reed”.