Paul Millar

Hi @rly, Indeed, I have restructured the format so that the items now have a container class, which is the `tree_root`. Adopting a container class turned out to be helpful...

The documentation has been update on master, with pull-request targeting 9.2: https://github.com/dCache/dcache/pull/7554 There is a patch that updates the oidc plugin so it provides more "reasonable" error message if there...

Just to add, I was able to reproduce this problem using system-test I added `xrootd.authz.user = 1000:1000,0` to the unauthenticated xrootd door: ``` [dCacheDomain/xrootd] xrootd.cell.name=Xrootd-${host.name} xrootd.net.port=1094 xrootd.authz.write-paths=/ xrootd.authz.user = 1000:1000,0...

Just to add a few comments: First, (in case this is in doubt) the behaviour is a bug. Second, the bug is in Chimera. One of the design decisions for...

Hi Arpad, dCache will provide a detailed explanation of a login failure in the log file (of the domain hosting gPlazma) the first time gPlazma sees a failed login attempt....

Hi Arpad, Could you copy (into this issue) the login failure report, as recorded in the domain log file (from the domain hosting gPlazma)? It should look like the `explain...

In your `explain login`, you asserted that you're a member of `/lofar/ops` group: ``` explain login "dn:CN=[...],C=DE" fqan:/lofar/ops ``` However, for the Macaroon request, you are presenting your EEC. There's...

I'm sure that Debian "bookworm" (v12) includes a newer version of podman, and so doesn't suffer from this problem. Therefore "simply" upgrading to bookworm should solve the problem this patch...

Hi @p12tic , > Are you still using podman-compose on bullseye? No. I've subsequently updated and I'm now using bookworm.

> Is that correct? Yes. If there are any explicit AuthZ statements in the token then the bearer (the client with the token) is authorised to make those operations (dCache...