Could you post a screenshot showing the effective eDirectory rights a given user object has to the ACL attribute of the NCP server object?

Here are the effective rights to the NCP server object for a random user who has excessive rights to folders of the NSS volumes:

However there are no trustee objects of the NCP server object that could inherit those rights to the user:

The user is not a member of DNSDHCP-Group object, which does not have excessive rights:

Neither do the [root] or [public] objects have excessive rights:

The only trustee objects with supervisor-rights are the NCP server object itself and the CommonProxy user:

I'd guess it's inherited from the owning (or any upstream) container / object. Quite often it's an assigment at tree level.

And just for the records: write rights to the ACL attribute (wherever they come from...) of a NCP server object imply unlimted filesystem rights to each and every volume hosted by the server in question.

So there's no need for further digging in the NSS area, this issue is driven by eDir rights.

But that's just the thing: I can't find any objects with such rights other than the NCP server onject and the CommonProxy user. Other than that there are only three Container Objects (tree > org > container) plus a small handful of groups. None of them have any rights for the NCP servers ACL attributes set at all.

Even a test-user with no security equivalences or group memberships in a new org container parallel in the tree to the one containing the NCP server object inherits full access rights.

tree
|- org
|  |- ncp-server
|  |- cn > affected-user
|
|- test-org > test-user

Hence the only possible culprit seems to be the tree object itself … but it only has explicit limited rights just one NCP object attribute.

But that's just the thing: I can't find any objects with such rights other than the NCP server onject and the CommonProxy user. Other than that there are only three Container Objects (tree > org > container) plus a small handful of groups. None of them have any rights for the NCP servers ACL attributes set at all.

Even a test-user with no security equivalences or group memberships in a new org container parallel in the tree to the one containing the NCP server object inherits full access rights.

tree
|- org
|  |- ncp-server
|  |- cn > affected-user
|
|- test-org > test-user

Hence the only possible culprit seems to be the tree object itself … but it only has explicit limited rights just one NCP object attribute.

No rights granted to [root] or [public]? To an "admin" object? Which are the effective rights to [root] for the random user mentioned higher above?

Okay the fix was somewhat bizarre. Thanks to Matthias Braun for putting me on the right track.

The tree object has these rights granted to itself:

Since [Entry Rights] had the only supervisor right granted I could find that might get inherited, I set it to "browse" instead. Result: Users have no file rights at all.
I then quickly set the [Entry Rights] back to "supervisor" and suddenly everything works as it should.

Be careful: once you grant [root] supervisory inheritable entry rights to itself everyone will be able to delete everything...

Advice noted! I will experiment with the inherit value when everyone else has gone home. At the moment there is no way for my users to edit the eDirectory rights and all file access rights now behave exactly as they should.

It's rather unusual for [root] to have ANY trustee assignments to itself.

Inherit is now removed, everything still works and supervisor rights no longer show up in any effective rights where they don't belong.

It is quite possible that our eDirectory is a little quirky. After all it does date back to the mid 1990s and has started from an even older migrated Netware bindery back then.

Does that mean that [root] still has supervisory rights to itself (just not inheritable anymore)? If so, ANYONE with a valid account can login, re-add the "inheritable" flag and delete everything. Or rename the tree (which would be possible right away, no inheritance needed. Or...

In contrast to this morning I have now set these rights:

Everything still works just fine and now should be safe again.

Still strange, but nothing which puts you at risk.

Strange sure! I don't see any rights assigned on the tree object to itself in a fully patched 24.3 server. We will review and see if this can be duplicated. Thanks for reporting bbsm  and great find Mathias Braun .