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.