Ubuntu 20.04 - Scans all files and then nothing at all

Hello everyone,

First post here :slight_smile:

Not sure what I should do here. I tried the “same” before under Windows and it worked perfectly (I even ditched PhotoPrism because of that). Any support is appreciated.

Problem
I re-ran now the index twice. It runs through all 23k~ pictures, but then is not displaying any of them.

The library folder under /home/user/Pictures is surprisingly empty.

Environment

System is definitely doing something:

Howdy, @Nighthawk , and welcome to PhotoStructure! Apologies that PhotoStructure is misbehaving for you.

There are a couple things going on (and possibly more): your library like like it’s on a remote filesystem, so PhotoStructure should detect that automatically and switch to “replica” mode. Read more here: What's PS_FORCE_LOCAL_DB_REPLICA?

It looks like PhotoStructure couldn’t write to the root directory of that share, so there’s no volume UUID for that mountpoint. It should defer to storing references with psnet URIs, but those can be problematic. Read more about this here: PhotoStructure | What's a “drive,” or “volume?”

If you can set PS_LOG_LEVEL=info and restart PhotoStructure, wait a bit, and then send me logs, that might shed more light on the situation as well. Detailed instructions are here: PhotoStructure | What are in my logs and error reports?

Thank you @mrm for your response, much appreciated you are taking the time.

your library like like it’s on a remote filesystem

No, it’s not. The library is on the local Ubuntu 20.04 VM (which sits on the NAS) within a PCIe SSD. There is only one linux user set-up.

That said, the /mnt/pictures/ folder is a NFS share, which sits on the same NAS but on another PCIe SSD (same setup worked before under Windows or with PhotoPrism, which is another product).

I will read the rest of your message more carefully tomorrow and follow-up again (I might also just start from scratch again or switch to Windows, where it worked just fine).

Thank you.

Ah, then PhotoStructure is mis-reading mount: you should set PS_FORCE_LOCAL_DB_REPLICA=false in that case.

(FWIW, although I have test rigs for Windows and macOS, I do most of my development and testing on an Ubuntu workstation).

@mrm , I have sent you a PM.

I re-installed Ubuntu 20.04 LTS from scratch and using the AppImage from your website. The library directory is rw (I tested it) and the NFS share (/mnt/pictures) is read-only and accessible (tested it as well).

Next step will be testing it with a SMB share instead NFS.

SMB with read/write permissions didn’t work at all (file browser can access the files just fine, but PhotoStructure can’t) …not even a log file got created…

The somewhat strange path got created by PhotoStructure when I selected the SMB share from the “Add” button…

Final test, from scratch again, was to copy the folder with the pictures into the library folder…and that worked successfully.

It looks like that the problem lies with the shares, but especially the NFS share should work in my mind…I can perfectly access it and copy from it to the local environment…why can’t PhotoStructure? What am I doing wrong?

@mrm I found the issue.

PhotoStructure doesn’t like read-only NFS shares at all. As soon as I changed the NFS share to read/write everything is working, which is good news, but personally I really don’t like this. Read-only access should be sufficient from my perspective.

Thanks for the updates!

I just DM’ed you: you can disregard the suggestion to manually create a .uuid file. PhotoStructure will have done that automatically as soon as the volume was writable.

After the .uuid file is there, you should be able to revert that mountpoint to be read-only.

There’s only one downside to read-only volumes: if you make any changes to your photos and videos, PhotoStructure won’t be able to drop sidecars next to your assets to record your metadata changes (or directly edit metadata, say, if you rotate an asset, and you’ve configured PhotoStructure to edit originals). Note that I’ve really tried to be careful with not mucking with originals: PhotoStructure don’t move files, even if “automatic organization” is enabled: PhotoStructure | Why doesn't PhotoStructure move original files?

SMB mounts can be done in several ways in Debian/Ubuntu desktops: either via the cifs driver, smbclient, or via gio. I have tests to validate all three work, but your box may be configured such that current volume parsing is breaking.

You can validate volume parsing with the info tool:

https://photostructure.com/server/tools/#system-information

Here’s an example

$ ./photostructure info --volumes
[
 {
   filesystem: '/dev/nvme0n1p2',
   mountpoint: '/',
   size: '491 GB',
   used: '389 GB',
   available: '76.9 GB',
   ignorable: false,
   remote: false,
   uuid: 'fb6bf27f-55d7-4919-a8dc-705b2432924b',
   volsha: '2NMQsMVCK'
 },
 {
   filesystem: '/dev/nvme1n1',
   mountpoint: '/mnt/c24fdf53-fc92-43ae-a1a5-9342d067b4a5',
   size: '983 GB',
   used: '449 GB',
   available: '485 GB',
   ignorable: false,
   remote: false,
   label: '1tb (test)',
   uuid: 'c24fdf53-fc92-43ae-a1a5-9342d067b4a5',
   volsha: '2NqM5Txc2'
 }
]

I just discovered that gio parsing is broken in both v1.1 as well as v2.0 prereleases: the next build will restore gvfs volumes.

I can confirm, I just switched to read-only and it still works (but I had to manually create the .uuid file). Thank you very much for the support!