This is not what I asked for, why would snapd have any errors
Well, what you asked for was totally unclear. My mistake for thinking that snapd might have something to do with snap functionality, obviously that was a crazy thing to think lol.
You could have said “grep journalctl for XX” or something, you know, actionable. Looking through potentially thousands of lines of logs for anything that might look like “a denial error” (not even a specific keyword) manually is not really feasible.
Since you still haven’t given any actionable advice for what to look for, I have grepped the journal for all mentions of snap, docker, and the paths in question, and there is nothing that looks like a “denial error”, which is as expected, since the behaviour is to silently perform incorrect behaviour, instead of erroring, which is basically my whole complaint.
Grepping for paths that work or the word “denied” interestingly turned this up:
<<DATE>> <<username>> kernel: audit: type=1400 audit(1730208612.533:139): apparmor="DENIED" operation="open" class="file" profile="snap.docker.docker" name="/myWorkingPath" pid=183085 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
But again, that is a path that worked correctly, so would not appear to be relevant.
You are making assumptions and accusations here but there is no data to back this…
No, sorry, this is incorrect.
There is very clear data to back pointing to snap:
- using the docker snap, binding to paths allowed in
mount-support.c
work correctly (the “magic paths”), paths not allowed there silently work incorrectly as described above
- using docker from apt, all paths work correctly
That is very obviously a snap issue, barring some really bizarre coincidence.
There might be some runtime or build time setting the docker binary has set/unset vs the Deb
It would be very curious if those settings were the same as the paths allowed/not allowed to snaps. Possible, but would be a strange coincidence. You should rather focus on what is most likely to be the issue, instead of wasting energy on doing trying to exonerate snaps in general, to use your turn of phrase.
there might be permission issues with your bind mount
There are not. I went through extensive testing of this, and again - that would not be resolved by switching from the snap to the deb, and so is irrelevant.
you might be needing to use a different target for the mount in the snap vs the Deb
Well, that would be a snap problem, wouldn’t it lol, and would not address the fact that the snap silently performs incorrect and undesirable behaviour.
I don’t use docker so I can’t tell, but I promise you that if you hit any snap boundaries the kernel will let you know about it
Well, you can try the test I gave above very easily without needing to know much about docker. I gave repro steps, it would be polite to at least give it a shot before getting rude, making vague and unhelpful responses, etc. lol
But again, the problem is that it doesn’t error. It just works incorrectly. I would love to get a descriptive error and have the bind mount simply fail. Besides warning other users about this (afaict) undocumented misbehaviour, that is the whole point of my post - errors need to be treated as errors, and not silently work incorrectly. I don’t think that should be controversial.
Nor should it be controversial that if the snap has the issue and the apt doesn’t, that snap is the culprit until proven otherwise.