On 7/5/23 03:39, Max Nikulin wrote:
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.
No they don't. This is apparently new to the search engines.
And so far as removing stuff, I will stop removing cups-browsed when it
allows brother's drivers to run my brother printers to their full
capability.
Which has zero to do with the fact that something is denying access to
my raid10 /home partition w/o logging a reason for the denial, for both
digiKam which cannot write to local storage in this raid10, and Kamosa
which can't even read the directory. So how about asking for me to
supply whatever data it takes to run down the cause and possibly the fix.
I suspect its something to do with some sort of ACL problem because it
all just worked under bullseye which depended on the ext4 file systems
triplet of access rights ONLY. For instance, where does this new,
expanded ACL system keep its logs? They don't seem to appear in
/var/logs. So where are they?
Thank you Max.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
