Which backup software did they use? And in which mode (smdr, xattr)?

Forgot to ask: did they change the host server on restore? ied. did they restore to the the VERY SAME instance or to a new one? Or maybe to a one with the same same as the original source?

Any news to this topic? I figured out today that my trustee rights also not working anymore.

At my volumes the trustee data base file exists and if i change some attributes via iManager the database will be updated but

at the moment every user have access to all files and folders on my volumes which is not good.

AUT_Tom said:

at the moment every user have access to all files and folders on my volumes which is not good.

A user will only have access as determined by the trustee rights. If no trustee rights have been assigned, a user will have no access.

View the trustee rights and inherited trustee rights for a file to see where the rights were granted.

Thats the point, as example for one volume absolutely no rights are granted and users can access without problems.
I have done my trustee config for so much folders and it worked as it should and no randomly i figured out that something went horrible wrong

AUT_Tom said:

Thats the point, as example for one volume absolutely no rights are granted and users can access without problems.

When you check the trustee rights for a file, you don't see any, right?

What do you see when you look at the inherited rights?

To be clear, i grant all users access to any folder on the volumes but i made exceptions to some folders for a couple of users.

My way to do that is to uncheck all flags of SRWCEMFA for my entiry user group and only grant rights to selected users as you can see on the pictures.

The strange thing is, that at the effective rights page all flags are marked and greyed out.

And when you look at the inherit rights page i'm not sure if the names where ever written in eDir syntax

Don't forget that once someone / something has been granted write rights to the ACL attribute of the NCP server object (of the server hosting the volume in question) he / she / it gains unlimited rights to the corresponding filesystems. The source of this eDir right can be virtually anywhere (via direct assignment, membership, equivalence, ... to the attribute, the object as such or somewhere far above in the tree). I've seen huge networks with supervisory granted to [public] at [root], often lurking around for decades (and likely set for troubleshooting purposes somewhen and forgotten later on).

So you might want to start checking the effective rights (of the object(s) having excessive FS rights) to the ACL attribute of the NCP server object which is tied to the volume in question. If you find rights to include "write" work yourself up the tree to find the reason.

Don't forget that once someone / something has been granted write rights to the ACL attribute of the NCP server object (of the server hosting the volume in question) he / she / it gains unlimited rights to the corresponding filesystems. The source of this eDir right can be virtually anywhere (via direct assignment, membership, equivalence, ... to the attribute, the object as such or somewhere far above in the tree). I've seen huge networks with supervisory granted to [public] at [root], often lurking around for decades (and likely set for troubleshooting purposes somewhen and forgotten later on).

So you might want to start checking the effective rights (of the object(s) having excessive FS rights) to the ACL attribute of the NCP server object which is tied to the volume in question. If you find rights to include "write" work yourself up the tree to find the reason.

At ACL attrib in NCP object only supervisor is written.

I tryed out now also to set access effective rights with the rights command  rights -f /media/nss/FOLDER -r none trustee username.benutzer.office.company

This was the output after:

All Effective Rights
------------------------
File: /media/nss/FOLDER
------------------------
(1) .CN=user.OU=benutzer.OU=office.O=company.T=COMPANY-TREE.
[supervisor, read, write, create, erase, access control, scan, modify]

So even i set no rights, the user get all possible rights

"Supervisory" implies "Write". If the the effective rights of "user.benutzer.office.company" to the ACL attribute of the NCP server object include S and / or W then "user" will have unlimited rights to all volumes hosted by this server.

So it means it is normal that the effective rights have all flags even i set the flags at the "normal" rights different?

The other question for me is right now, from which services the NSS trustee right system is appending,.except from eDir.

If you have the supervisor right, this right flows down the whole structure and this cannot be inhibitet by an Inherited Rights Filter. You have to find, where this right is set, because you see only rights granted at the volume level or below - rights you set at the tree level or at container level above the servers or the servers you do not see in the trustees list of th volume or a directory or file.

Look at the trustees of the tree, as there are often quite interesting trustees set. You will find public to be one of the trustees of the tree - and if there are to much rights granted to public - everybody will be an administrator of all objects and files in the tree.

As mentioned: once someone has W (or S) rights to a NCP server's ACL attribute he has unlimited rights to all volumes hosted on this server. This is regardless of the rights granted (or revoked) at the filesystem level. It is the only point where eDir rights have influence on filesystem rights. Please simply post a shot showing the effective eDir rights which "user.benutzer.office.company" has on the ACL attribute of the NCP server object in question.

You mean that?

Exactly. This means that xxx.benutzer.office.xxx has unlimited rights to all filesystems hosted on this server.

Now walk up the tree to find out from which point on the user has excessive rights. Once the context is found you can check how these rights were assigned. This could be via a direct assignment, a group, a context, equivalence, role, [public], [root], even via an assignment to [self].