Docker - Bind Mount Import Folder Issues (Shown/Unshown, Duplication)

Support
1

Hey Matthew,

I think we discussed this a few times via Discord. The behavior I was experiencing previously was that if I set up my docker-compose like so:

  photostructure:
    volumes:
      - $MEDIADIR/photos:/photos
      - $DOCKERDIR/photostructure:/ps/library
      - $DOCKERDIR/photostructure:/ps/library/.photostructure
      - /mnt/storage/sync/user/Pictures/ERH 2020:/ERH2020
    environment:
      - TZ
      - PUID
      - PGID
      - UMASK=002
      - PS_ORIGINALS_DIR=/photos

And then with automatic management, Photostructure would pull the photos from /ERH2020 into /photos as I expected.

Subsequently, issues abound if I removed that bind mount of /ERH2020. When doing a re-sync or rebuild it appeared the assets would swap from shown=1 to 0, back to 1, etc. - hard to pin down. My goal is to use something like /import as a temporary bind mount to grab photos from… wherever… on my host, load them, then point the bind mount to a new location and import more photos - eventually removing the photos from their disparate locations except for within /photos.

However, I just stumbled upon a discovery. If I do the following:

1. Set up compose as stated
2. Launch PS
3. Rebuild the container without /ERH2020
4. Rebuild library

PS appears to copy the photos back out of /photos into a path of /ERH2020 that exists only in the container because it is no longer bind mounted. Perhaps this is part of the issue? If I remove a bind mount and run a rebuild, I would expect the photos should only have an assetFile location of the library itself and the old location be scrubbed, not have that old location be rebuild within the container itself. Does that make sense?

Happy to send whatever logs. Here’s some commands from inside the container:

Thanks.

Edit: It appears it was still bound as I had a duplicate bind mount, so disregard that ‘new finding’ that I thought was helpful. The shown/unshown issue however is still persistent. I can try to recreate the issue with discrete steps if that’s helpful. Please let me know.

If I do a rebuild with the bind mount and photos in place, then remove the bind mount and rebuild, suddenly it shows me I have 0 assets even though all files are still in the /photos originalsDir.

2

Howdy @adamf , thanks for the bug report!

There were a couple issues that might be causing this grief in the last alpha build:

  1. Nested mountpoints could cause issues with sync–it shouldn’t have walked into new mountpoints, and it may have

  2. Mountpoint parsing had a couple issues that I just found and fixed, which could have resulted in only a partial list of mountpoints being detected.

  3. alpha builds prior to 4 have quite broken exclude lists (thanks to the new-to-that-version globs setting). The next build should resolve this.

Note that 1. and 2. would result in incorrect asset file URI generation, which would result in a bunch of things breaking.

Not to say, of course, that there may be yet other issues also causing grief, but there’s a non-zero chance that the current bugfixes may address the sync-doesn’t-recurse-properly error.

3

Hey @mrm,

This issue has been happening for a few weeks but I thought I’d file it here for tracking. When it initially occurred I was not nesting mountpoints as I only started testing that within the last two days. I also am not using any exclude lists (as far as I know? Would it be another environmental variable?).

I believe I had sent you a database export that was showing the assets as shown=1 but they still weren’t rendering on the page in browser. This was after removing the temporary (in this case, /ERH2020) mountpoint, but leaving /photos intact as my originalsDir. Only after re-adding the second mount point and running a sync or rebuild (I forget which, would need to reconfirm) did the images reappear.