On 05/07/2023 12:43, gene heskett wrote:
On 7/4/23 23:14, Max Nikulin wrote:
On 04/07/2023 22:06, gene heskett wrote:
or deb which appears to be a snap
Debugging of snap and similar isolation technologies heavily relying
on namespaces (mount and other ones) sounds like an off-topic in the
thread where udisks2 magic is the most likely issue.
Sorry to offend, but that was precisely my point. There appears to be
a clash in ACL's for camera apps,
Gene, do not confuse udisks2 and udev.
one that does NOT generate a visible error msg. digikam cannot write
to my raid10 /home storage, and Kamosa can't even read it, saying
/home/gene/Pictures with over 8000 images in several subdirs, is empty.
From my point of view, it just confirms that your troubles may be
related to snap (that is another layer of complexity) or to rather large
applications like digikam. If you believe that snap is unrelated then
describe your problem accordingly and mention secondary components only
as a part of the goal you are trying to achieve.
Notice that Hans nicely isolated the issue to ls and getfacl output.
Any blocking by app acls would have to start in udisks2 ack what I'm
reading.
You tend to generalize too much.
If that is not the case, please explain how to fix, and what to fix
since it all Just Worked with bullseye.
In the Hans' case I may assume a configuration close to defaults. In
your case I have to expect arbitrary broken system. It may be caused by
removing of some component you do not like or even terribly damaged udev
configuration due to attempts to fix 3D printers access by their serial
IDs.
I do not remember whether you have followed a suggestion to try udev
monitor, but if you decide to do so, it will be better to keep
discussion within that thread.
Search engines may give enough hints how to debug particular components.