leads me to agree with @paperdigits. Why not use the PPA? You won’t need to change OS to something unfamiliar (Win 10 is not the Windows of 10 years ago), you won’t have to deal with the
confinement implemented in the snap, and you won’t have to deal with the bloat of what’s included in the snap.
Everything is harder when it’s late and you’re frustrated.
As I mentioned before, I know nothing about snap packaging, so I would have to do some learning myself in order to be able to help you. But I’m pretty sure that those who do know a thing or two would want:
the Mint release (19.2, you provided that)
the darktable snap release
the actual messages issued when it failed to access the removable media, or an indication that there were none
the actual output from executing the sudo snap connect darktable:removable-media command
They may want more, but that’s what comes to mind right away.
@strom019 I’m sorry for the frustration. I’m not trying to be mean by confining the snap to only be useful in a few places, it’s just how snaps work. Snaps don’t give me the ability to say “Hmm, I’d say everyone only keeps their images in /foo/bar, thus I’ll make a snap that can only access that location.” They provide a few general purpose interfaces (e.g. the home interface allows access to $HOME, removable-media allows access to /media/ and /mnt/, etc.). I’ve added support for every interface that can be connected to expand where it can read/write, but snaps aren’t quite at the android level of permissions that I’d love to see (e.g. “hey, okay with you if the snaps writes <here>?”).
It means that, assuming you connect the removable-media interface, the darktable snap can read/write in the following places:
Anywhere in $HOME (but not dot folders IN $HOME)
Anywhere in /media/
Anywhere in /mnt/
Is it possible that you’re not just trying to import stuff from another hard drive, but that you’re hitting this bug? I haven’t been able to figure out how that functionality works in darktable to properly debug why it’s not working.