Did they use metamig to save the trustee rights? With metamig you should be able to restore trustee rights, if they are still there or stored somewhere.

I don't know how they backed up the file system, but in my experience everything outside of smdr and tsafs can result in problems, if the server is running during backup, as almost no tool is capable of dealing correctly with nss-volumes nowadays. I had all sorts of issues with backups of nss-volumes from outside of the OS like backups at the VMFS level or at the SAN level - they all mounted and started to be usable, but either got unaccessible over some period of time (hours), or had strange not persistent trustee rights and all those issues were not easily repareable. This in contrast to linux filesystems like ext4, btrfs, xfs etc. and Windows filesystems, which always worked flawlessly after such a restore.

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.

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