Thought I had it, but no? these directories should be, right, no?
paths are case-sensitive on QNAP (being a linux based system). If you know how to shell/ssh into your NAS, it’s probably the best way to validate paths. Meanwhile, try /DataVol1/Public/Photos see if it makes it all better.
1 Like
Sorted that now it looks like that you, would never have found out the proper name!
Now trying to figure out why it can’t find the path for ${HOME} in the script, I can’t see any where on there where ${HOME} is matched upto anything which feels odd, but again I’m not well versed on it.
If you’re using :alpha, use “easy mode” which lets you delete the /ps/tmp, /ps/config, and /ps/logs bind mounts.
Those ${HOME}/... paths were just defaults, BTW.
Oh right, I didn’t even notice the ${HOME} binds you had… I can’t imagine those would work in qnap / portainer
Christ I hate myself for asking so many questions, but im really just creating a template with the below!? from your easy mode post.
…I can already see myself dragging my arse back to Apple Photos or something else awful lol
Ah… think I’ve managed to fudge it… lets see! got rid of the $home bit and just put in the direct paths…
Head in hands.
Maybe this really is just something for non Joe Public 
I think those instructions might be a bit incomplete. A docker container can’t see anything outside of its sandbox unless you map it, so you need to bind mount TWO folders at a minimum.
- #1 for the Photostructure library - that’s where PS will store its data. So /ps/library should be mapped to somewhere that is exclusively for photostructure to work in. For example, /DataVol1/Public/Photostructure.
- #2 where your photos you want PS to scan. A container can’t see anything outside of its sandbox, you have to explicitely mount it. So you may mount /DataVol1/Public/Photos to /media inside the container.
Might look something like this:
docker run \
--stop-timeout 120 \
-v /DataVol1/Public/Photos:/media \
-v /DataVol1/Public/Photostructure:/ps/library \
photostructure/server:alpha
If you could cut and paste what you did specifically, I am sure we can help.
1 Like
Here, I screen recorded (and narrated) how to install photostructure on docker using portainer. I hope it helps.
3 Likes
HOLY MOLY THIS IS AMAZING.
Thanks for taking the time to record that, @avdp!
Is it OK for me to link to this video in the documentation?
(And yes, I just figured out how Discourse Badges work so I could give you one…)
sure no problem
Amazing!! thats awesome of you, and to be honest, I’m glad it will help others in my position 
I’ve now managed to ‘sort of’ get it working thanks to that… I dumped a test photo into the binder media dir on the NAS, and I can see PhotoStructure has pulled it in and placed it into a dated folder as specified (told it to copy). However… there is no photo displayed in the actual photostructure app, which is odd I’d say! maybe its a alpha issue which is possible I guess…?
Sync log looks to have some funky error…
sync-124-001.log (139.2 KB)
OK, progress. Progress is good. I am not seeing anything too alarming in the log… In fact the log shows the pic was processed successfully all the way through. but @mrm would definitely be better at looking at that.
It is odd that the status on sync is “new” … can you do a “restart sync” (from the sidebar menu) and/or restart the container.
Try dropping a few pictures in there to test.
Lastly, take a look at the sync-reports to see if the pic was skipped, although again the log does not show that it was.
Hmm so, the latest sync report looks fine -
I did the sync restart this time and got an sql error, ooooh - but I will say, on the previous container (I’ve re-created it a few times to see if an error on my end/glitch) I did the same restart sync and got no error, at least that I noticed from the dashboard.
web-36-001.log (72.9 KB)
I can also add, that when trying to import more - they aren’t processing.
yes, indeed. The dreaded SQLITE errors. I’d like to say those are just alpha issues, but I was experiencing those with prior releases as well. All I can say is that setting PS_FORCE_LOCAL_DB_REPLICA to false was helpful for me on prior releases, although I can’t explain why. Now you’re definitely in @mrm territory for assistance with this.
{"ts":1657802602992,"l":"warn","ctx":"express.ServerToastHelpers","msg":"sendServerToast()","meta":{"requestedURI":{"$mid":1,"path":"/api/system","scheme":"http","authority":"192.168.1.230:1787"},"toast":{"text":"Well, darn, that didn't work","uuid":"SqliteError: SQLITE_CORRUPT: database disk image is malformed","details":"SqliteError: SQLITE_CORRUPT: database disk image is malformed","type":"warning","button1Text":"Return home","button1Url":"/tag#dismiss","button1Class":"info","onClickUrl":"#dismiss"},"httpStatusCode":500}}
Thank you - yes I had input that setting into the creation of the container (PS_FORCE_LOCAL_DB_REPLICA) as per the video.
Fingers crossed we get somewhere now we’ve come so far! lol
@avdp are there other debug logs you can send me for the SQLITE_CORRUPT issue? I have wishes, nay, dreams, of a hallowed ray of light to descend upon my git diffs and rid us of this unfair, unjust and unwanted torment. I’d like to fix this issue.
Hahahaha