On 06/07/2023 18:57, gene heskett wrote:
gene@coyote:~$ findmnt --target /home/gene/Pictures/Saw4Bruce (didn't work)
TARGET SOURCE FSTYPE OPTIONS
/home /dev/md0p1 ext4 rw,relatime,errors=remount-ro,stripe=256
gene@coyote:~$ findmnt --target /home/gene/Pictures/Newjuly5dlds (worked)
TARGET SOURCE FSTYPE OPTIONS
/home /dev/md0p1 ext4 rw,relatime,errors=remount-ro,stripe=256
Looks like a purely application issue unrelated to udev, camera, etc.
Can you add more photos to Newjuly5dlds? To factor out camera
completely, can you copy images withing digikam to these directories?
Have you inspected folder (album?) properties as it represented by
digikam? Are these directories contain files that are not images and
that may contain metadata declaring that some directory should be
"protected from writing"? Does digikam use akonadi? Does it connect to
the session-wide instance or it runs another one in container? Maybe the
application believes that some directories are managed by another
application and tries to protect you from a conflict.
If you believe that the issue is at a lower level and your way to run
digikam really uses namespaces, you may try to inspect its environment by
nsenter --all -t PID_OF_DIGIKAM
e.g. output of "mount". However it is better to compare at first that
ls -l /proc/$$/ns
ls -l /proc/PID_OF_DIGIKAM/ns
do not identical
A sledgehammer for obscure issues is attaching to a process by strace.
After all, have you checked ~/.xseession-errors (if it is still in use)?
