How can I configure a Recycle Bin in TrueNAS where deleted files are only accessible by specific group administrators?

Hello,
I’m using TrueNAS and I would like to configure a system where deleted files are sent to a recycle bin instead of being permanently removed. However, I only want specific group administrators to have access to these deleted files in the recycle bin, while regular users cannot see them.

Is there a built-in way to do this in TrueNAS? Or would I need to set up a custom dataset and modify permissions to achieve this functionality?

Any suggestions on how to configure this properly would be greatly appreciated!

Thanks in advance!

You can’t. Minimally the user needs the ability to rename the file to the recycle bin.

How, I don’t understand.

That’s how the feature works. When a user deletes a file, the delete operation is converted to a rename as the same user. The file is renamed so that its location is in .recycle.

Hi, I’m not sure exactly what you’re trying to achieve here but perhaps snapshots and previous versions would be better?

I’m happy to let my users delete their data but I don’t let them have access to previous versions just incase they decided to rollback a parent folder screwing over other users. If they need a file or folder recovering they ask us and we can do the rest.

I want only administrators to have access to this created folder.

Take a step back and ask yourself exactly what you are trying to achieve.

I presume you want a process whereby if a user deletes a file or folder then you want an administrator and only an administrator to have the ability to recover it. Is that correct?

@awalkerix out of interest is it or would it be possible to expose previous versions to only a defined group such as storage administrators?

yes, that’s exactly it.

No. Not possible. Changing recycle bin behavior is also not possible without change to vfs module design. This is not something where a person can make a config change from shell and make it work.

In theory someone could turn off the ZFS snapdir entirely and then clone the snapshot and make a private share, then manually delete the share and then delete the clone.

But it does raise the question about what the actual threat model is here and whether it makes sense to go through all the hoops to begin with.

1 Like

Ok so I think snapshots are the way. The tricky bit is how your IT people recover the data.

Option 1. Keep previous versions disabled in the SMB share config by default but enable it when an IT admin needs to map and recover using previous versions remembering to disable it afterwards.

Option 2. Recover the data from the shell if IT admins are happy with that process and if you are happy to let them dance around the shell (I wouldn’t be).

Option 3. If you replicate your TrueNAS to another regularly then have the share/s exposed on the recovery system with previous versions enabled and IT can map to that server and copy the data across as needed (this is what I do).

That’s problematic because the .zfs/snapdir hidden directory may still be available. That said, I really don’t understand the risk model here. The current version of the file is OK, but somehow an old version isn’t.

1 Like

Ah ok. Down to Option 2 & 3 then.

Agreed, if you are exposing the recycle bin then one assumes you are trying to make users more self sufficient and would want them to be able to recover deleted files themselves.

As I mentioned above I completely get why you wouldn’t want users to have access to previous versions as they could do stupid things but that doesn’t appear to have been the main issue here.

This feature needs to be implemented.
Users may intentionally delete a file while working on a project. In this case, the admin can know who deleted which file and report it to their superiors.
It’s annoying that TrueNAS doesn’t have a button for something that QNAP does.

We use logs to identify this.