Unable to Delete .recycle directory

[pfong]

Hi,

I have a simple TrueNAS SCALE 23.10.2 setup using two set of mirrors (4 drives). One set of drive mirrors I use often to store documents. I often open the documents using MS Word or LibreOffice. The Share Type: SMB with Purpose: No presets, and Export Recycle Bin Enabled. In Windows 11 23H2, I have the Show hidden files, folders, and drives Enabled.

I would open, edit, and save directly in the SMB share, hence a temporary file is created and then deleted either by LibreOffice or MS Word automatically when I close those programs. These temporary files are moved to the hidden .recycle directory. Every once in a while, I would review my deleted files along with those temporary files. The *.tmp & ~$**** files, I would simply delete. I often just delete the .recycle, and TrueNAS auto creates a fresh one when needed.

I saw that the temporary files are ALL properly deleted, but TrueNAS always leaves a few empty directory behind. When I try to delete those empty ditrectories from Windows 11 share, nothing happens, no indications of permission violation or anything. I can rename those empty directories within Windows share, but just cannot delete them.

I can also delete those empty directories within .recycle from the TrueNAS shell without issue, but I just cannot delete them from Windows share, which has the Show hidden files, folders, and drives Enabled. Currently I just let the number of undeletable empty directories within .recycle pile up before deleting them from the shell.

There must be a reason why I can rename the empty directories, but not delete them. I remember having this exact same issue when I was using TrueNAS Core about 3 years ago, and this issue was fixed in a later release. The temporary files & directories are created by MS Word and LibreOffice when opening, closing, and/or saving files.

Has anyone else seen this issue before? Does anyone have a clue on how do I fix it so that I can delete those empty directories from Windows.

Thanks....
Peter

 

[artlessknave]

i would highly recomend against deleting .recycle. i would guess that you have confused the .recycle function by deleting it's folder.

I would disable .recycle for the share, then use the shell and "rm -rfv" it into oblivion.

note, however, that "rm -rf" is a great power, and with great power...comes great responsibility. be DAMN sure you are using it in the right place.

 

[pfong]

Thank for the excellent advice artlessknave:

I'm just still just not accustomed with the concept of ZFS snapshots. I'm more use to the recycle bin concept

But I use a batch script to hash files (was sha512, now Blake3) as an added layer of protection because recently TrueNAS Scale will delete your files to oblivion if it is larger than 20MB, not move it to .recycle. Every week I'd run a batch file on my Win11 PC which hashes my Docs Share (contains only PDFs, docx, odt, etc) and store the dated checksum files on that share (sorted, sed cleaned). I'd first run a compare of the previous weeks' checksum files with the current checksum file using NotePad++. Any RED highlights on the left pane (rarely), I'd double check that I'd really wanted to delete that file or its an updated file. GREEN highlights, always on right pane are added files. Afterwards, I'd review .recycle bin manually and delete the temp files and any PDFs, docx, odt, ppt, etc... I'd also run a dated WinRAR backup of everything every other week or monthly when I there are little changes, on a set of three different branded 128GB USB flash drives with 10% ecc recovery code. Unimportant files on other shares, I just do a robocopy mirror backup to an external USB HDD. I'd do three backups in a row whenever I upgrade TrueNAS or destroy the pool. Been doing this, overly cautious approach, in my opinion, for a couple of years).

I think somehow this is a bug/quirk of TrueNAS Scale's SMB share in how it configured SMB which "sometimes" does not allow Windows to delete directories created by External programs, strange that I can rename them. I mapped it to Z: and tried deleting it using "rd /s" and Windows says the directory is not empty, even though "rd /s" should delete directories along with files. I remember TrueNAS Core had this issue and was fixed in a later version.

This .recycle bin quirk & the inability to send beeps when TrueNAS Scale is ready are the two things I can't seem to find a solution to, which TrueNAS Core does not have the issue.

-Peter

 

[anodos]

Bas an added layer of protection because recently TrueNAS Scale will delete your files to oblivion if it is larger than 20MB, not move it to .recycle.

Can you provide more information about this? There is no such size limit related to recycle bin operations (it simply renames the file to a new path).

 

[pfong]

Can you provide more information about this? There is no such size limit related to recycle bin operations (it simply renames the file to a new path).

Hi,

In the latest TrueNAS SCALE 23.10.2 under SMB Shares, if you click the "?" that is circled next to "Export Recycle Bin" it states:

Help: Export Recycle Bin
Files that are deleted from the same dataset are moved to the Recycle Bin and do not take any additional space. Deleting files over NFS will remove the files permanently. When the files are in a different dataset or a child dataset, they are copied to the dataset where the Recycle Bin is located. To prevent excessive space usage, files larger than 20 MiB are deleted rather than moved. This is not a replacement for ZFS snapshots.

Anyhow, I'm not exactly sure which version TrueNAS started doing this, but it got me "scared", so I added the dated checksuming step to my data safety procedures and ONLY cleaned out this .recycle once a week or less. And backups were made before & after deletions so that I can "rollback" and mistakes. And I automate everything (from checksumming, backup, then verification) with windows batch scripts, to remove as much of the "human" error as possible for my particular use case.

-Peter

 

[anodos]

Hi,

In the latest TrueNAS SCALE 23.10.2 under SMB Shares, if you click the "?" that is circled next to "Export Recycle Bin" it states:

Anyhow, I'm not exactly sure which version TrueNAS started doing this, but it got me "scared", so I added the dated checksuming step to my data safety procedures and ONLY cleaned out this .recycle once a week or less. And backups were made before & after deletions so that I can "rollback" and mistakes. And I automate everything (from checksumming, backup, then verification) with windows batch scripts, to remove as much of the "human" error as possible for my particular use case.

-Peter

That text blurb is incorrect. I'll open a docs ticket to get it fixed. That said, as mentioned in the tooltip, using this in lieu of a snapshot schedule is a bad design decision.

 

[artlessknave]

But I use a batch script to hash files (was sha512, now Blake3) as an added layer of protection because recently TrueNAS Scale will delete your files to oblivion if it is larger than 20MB, not move it to .recycle. Every week I'd run a batch file on my Win11 PC which hashes my Docs Share (contains only PDFs, docx, odt, etc) and store the dated checksum files on that share (sorted, sed cleaned). I'd first run a compare of the previous weeks' checksum files with the current checksum file using NotePad++. Any RED highlights on the left pane (rarely), I'd double check that I'd really wanted to delete that file or its an updated file. GREEN highlights, always on right pane are added files. Afterwards, I'd review .recycle bin manually and delete the temp files and any PDFs, docx, odt, ppt, etc... I'd also run a dated WinRAR backup of everything every other week or monthly when I there are little changes, on a set of three different branded 128GB USB flash drives with 10% ecc recovery code. Unimportant files on other shares, I just do a robocopy mirror backup to an external USB HDD. I'd do three backups in a row whenever I upgrade TrueNAS or destroy the pool. Been doing this, overly cautious approach, in my opinion, for a couple of years).

I, frankly, cant make it through this wall of text; my eyes glaze over

it sounds like you are purposely mangling the purpose of zfs (checksums) and manually trying to checksum everything?

this whole function is covered by snapshots and replication in a handlful of set-it-and-for-it configuration screens.

I dont even have the "recycle bin" enabled. it worked like (^*% I found.

you can accomplish a far and away better equivalent by simply presenting the snapshots to windows using the "previous versions" functionality of samba.

 

[pfong]

I, frankly, cant make it through this wall of text; my eyes glaze over

it sounds like you are purposely mangling the purpose of zfs (checksums) and manually trying to checksum everything?

this whole function is covered by snapshots and replication in a handlful of set-it-and-for-it configuration screens.

I dont even have the "recycle bin" enabled. it worked like (^*% I found.

you can accomplish a far and away better equivalent by simply presenting the snapshots to windows using the "previous versions" functionality of samba.

I'm still kinda stuck to the old way of doing things. I use to use "unreliable" CD-R/RW disks, then "better" but still a bit unreliable USB flash drives/USB HDDs attached to my computer as the "NAS-like" storage medium. The reason for my check summing habit was because my CD-R/RW disks (developed pits/discolorations as they aged) & USB drives sometimes degraded and had data corruption issues.

I guess I'm still seeing/treating the NAS like a "More-Reliable-Super-Sized" USB drive that is shareable without manually plugging.

I've been quite busy with other stuff for many years & will try to brush-up on the newer NAS technology that has made everything easier to accomplish & change some of my overly complicated procedures. I still got a decade-old FreeNAS system that I will try to upgrade to TrueNAS when I have time.