4 minutes ago, bigfoxtail said:

I re-investigated the issue.

Based on my analysis, it appears to be caused by .Recycle.Bin being combined with the %P parameter.

%P is an absolute path, and after being concatenated by the module, the resulting parameter becomes:

recycle:repository = .Recycle.Bin/%P

During deletion, the final recycle bin path ends up in the following format:

/mnt/z/file/.Recycle.Bin//mnt/user/file/ff/Games/

The double slash (//) in the middle causes Samba to fail when parsing the path.

I modified the concatenation logic for recycle:repository. You can try this package.

I tested the recycle bin functionality, and it seems to be working fine now.

😁

plugin error fix: https://raw.githubusercontent.com/bigfoxtail/recycle.bin/refs/heads/master/recycle.bin.plg

https://github.com/bigfoxtail/recycle.bin

Using parameters other than %P should avoid the issue
PANIC (pid 2198065): assert failed: rel_fname.base_name[0] != '\0'.

1 hour ago, bigfoxtail said:

Using parameters other than %P should avoid the issue
PANIC (pid 2198065): assert failed: rel_fname.base_name[0] != '\0'.

You proposed solution will still be a problem. The %P parameter is not supported in later versions of samba and should not be used at all. There are recycle bin parameter settings that will enable the %P action by default. These settings are not set properly in the current release of the recycle bin plugin.

On 1/16/2026 at 11:19 PM, dlandon said:

You proposed solution will still be a problem. The %P parameter is not supported in later versions of samba and should not be used at all. There are recycle bin parameter settings that will enable the %P action by default. These settings are not set properly in the current release of the recycle bin plugin.

It appears that the %P parameter has not been deprecated.
Both the official documentation and the current source code indicate that %P is still supported:

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

https://gitlab.com/samba-team/samba/-/blob/master/source3/lib/substitute.c?ref_type=heads

Based on the wiki and the latest source, %P seems to be working as expected.
As for future versions, ongoing development will be in your hands.

thanks😁😁😁

In any case, the delete functionality is now behaving correctly, which is sufficient for my current use case.

4 hours ago, bigfoxtail said:

It appears that the %P parameter has not been deprecated.
Both the official documentation and the current source code indicate that %P is still supported:

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

https://gitlab.com/samba-team/samba/-/blob/master/source3/lib/substitute.c?ref_type=heads

Based on the wiki and the latest source, %P seems to be working as expected.
As for future versions, ongoing development will be in your hands.

thanks😁😁😁

In any case, the delete functionality is now behaving correctly, which is sufficient for my current use case.

I mis-spoke about Samba not supporting the %P. It is supported but should not be used in the vfs recycle module.

According to ChatGPT:
"%P is valid in Samba generally, but it is not handled safely by the vfs_recycle module. When used in recycle:repository, it can generate invalid paths and lead to smbd instability.

There are recycle bin configuration options that correctly handle directory structure without relying on %P, and those should be used instead."

The current implementation of the recycle bin plugin does not set those recycle bin options. The %P should not have been used in the recycle bin plugin originally.

7 hours ago, dlandon said:

I mis-spoke about Samba not supporting the %P. It is supported but should not be used in the vfs recycle module.

According to ChatGPT:
"%P is valid in Samba generally, but it is not handled safely by the vfs_recycle module. When used in recycle:repository, it can generate invalid paths and lead to smbd instability.

There are recycle bin configuration options that correctly handle directory structure without relying on %P, and those should be used instead."

The current implementation of the recycle bin plugin does not set those recycle bin options. The %P should not have been used in the recycle bin plugin originally.

Yes. %P generates an absolute path, and when it is concatenated with .Recycle.Bin/, it results in a path like .Recycle.Bin//folder. The double slash (//) likely causes Samba to interpret it as an empty path, which then triggers the error.

I finally got round to looking at this again.

This time I tried uninstalling, renaming the remaining config folder from the flash drive, updating unraid and reinstalling the plugin.

So far things seem to be working, going off the above, I'll note the parameters is blank now.

I just reinstalled the plugin after upgrading to 7.2.4, and it still panics. Any ideas?



Mar 12 15:47:49 Soundwave smbd[131285]: [2026/03/12 15:47:49.662864, 0] ../../lib/util/fault.c:192(smb_panic_log)

Mar 12 15:47:49 Soundwave smbd[131285]: PANIC (pid 131285): assert failed: rel_fname.base_name[0] != '\0' in 4.22.8

Mar 12 15:47:49 Soundwave smbd[131285]: [2026/03/12 15:47:49.663472, 0] ../../lib/util/fault.c:303(log_stack_trace)

Mar 12 15:47:49 Soundwave smbd[131285]: BACKTRACE: 33 stack frames:

Mar 12 15:47:49 Soundwave smbd[131285]: #0 /usr/lib64/libgenrand-private-samba.so(log_stack_trace+0x29) [0x149227c165b9]

Mar 12 15:47:49 Soundwave smbd[131285]: #1 /usr/lib64/libgenrand-private-samba.so(smb_panic+0x9) [0x149227c16849]

Mar 12 15:47:49 Soundwave smbd[131285]: #2 /usr/lib64/libsmbd-base-private-samba.so(openat_pathref_fsp_nosymlink+0x35b) [0x149227fd509b]

Mar 12 15:47:49 Soundwave smbd[131285]: #3 /usr/lib64/libsmbd-base-private-samba.so(filename_convert_dirfsp_nosymlink+0x589) [0x149227ff4da9]

Mar 12 15:47:49 Soundwave smbd[131285]: #4 /usr/lib64/libsmbd-base-private-samba.so(filename_convert_dirfsp_rel+0xb9) [0x149227ff5939]

Mar 12 15:47:49 Soundwave smbd[131285]: #5 /usr/lib64/libsmbd-base-private-samba.so(fd_openat+0xf9) [0x149227ff8e49]

Mar 12 15:47:49 Soundwave smbd[131285]: #6 /usr/lib64/libsmbd-base-private-samba.so(+0x5276c) [0x149227fd476c]

Mar 12 15:47:49 Soundwave smbd[131285]: #7 /usr/lib64/libsmbd-base-private-samba.so(openat_pathref_fsp+0x1d2) [0x149227fd7832]

Mar 12 15:47:49 Soundwave smbd[131285]: #8 /usr/lib64/libsmbd-base-private-samba.so(synthetic_pathref+0x33) [0x149227fd7ae3]

Mar 12 15:47:49 Soundwave smbd[131285]: #9 /usr/lib64/vfs/recycle.so(+0x36e0) [0x149222f1f6e0]

Mar 12 15:47:49 Soundwave smbd[131285]: #10 /usr/lib64/libsmbd-base-private-samba.so(close_file_smb+0x789) [0x149228005109]

Mar 12 15:47:49 Soundwave smbd[131285]: #11 /usr/lib64/libsmbd-base-private-samba.so(+0xbaafb) [0x14922803cafb]

Mar 12 15:47:49 Soundwave smbd[131285]: #12 /usr/lib64/libsmbd-base-private-samba.so(smbd_smb2_request_process_close+0x1fe) [0x14922803d53e]

Mar 12 15:47:49 Soundwave smbd[131285]: #13 /usr/lib64/libsmbd-base-private-samba.so(smbd_smb2_request_dispatch+0x10f4) [0x149228030044]

Mar 12 15:47:49 Soundwave smbd[131285]: #14 /usr/lib64/libsmbd-base-private-samba.so(+0xaf0f8) [0x1492280310f8]

Mar 12 15:47:49 Soundwave smbd[131285]: #15 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x149227bc7c41]

Mar 12 15:47:49 Soundwave smbd[131285]: #16 /usr/lib64/libtevent.so.0(+0x100ae) [0x149227bcf0ae]

Mar 12 15:47:49 Soundwave smbd[131285]: #17 /usr/lib64/libtevent.so.0(+0xdb37) [0x149227bccb37]

Mar 12 15:47:49 Soundwave smbd[131285]: #18 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x8f) [0x149227bc6d9f]

Mar 12 15:47:49 Soundwave smbd[131285]: #19 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x149227bc709b]

Mar 12 15:47:49 Soundwave smbd[131285]: #20 /usr/lib64/libtevent.so.0(+0xdad7) [0x149227bccad7]

Mar 12 15:47:49 Soundwave smbd[131285]: #21 /usr/lib64/libsmbd-base-private-samba.so(smbd_process+0x84c) [0x14922801eb3c]

Mar 12 15:47:49 Soundwave smbd[131285]: #22 /usr/sbin/smbd(+0xb21a) [0x5591b2eb421a]

Mar 12 15:47:49 Soundwave smbd[131285]: #23 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x149227bc7c41]

Mar 12 15:47:49 Soundwave smbd[131285]: #24 /usr/lib64/libtevent.so.0(+0x100ae) [0x149227bcf0ae]

Mar 12 15:47:49 Soundwave smbd[131285]: #25 /usr/lib64/libtevent.so.0(+0xdb37) [0x149227bccb37]

Mar 12 15:47:49 Soundwave smbd[131285]: #26 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x8f) [0x149227bc6d9f]

Mar 12 15:47:49 Soundwave smbd[131285]: #27 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x149227bc709b]

Mar 12 15:47:49 Soundwave smbd[131285]: #28 /usr/lib64/libtevent.so.0(+0xdad7) [0x149227bccad7]

Mar 12 15:47:49 Soundwave smbd[131285]: #29 /usr/sbin/smbd(main+0x14ac) [0x5591b2eb134c]

Mar 12 15:47:49 Soundwave smbd[131285]: #30 /lib64/libc.so.6(+0x2ad14) [0x1492279d9d14]

Mar 12 15:47:49 Soundwave smbd[131285]: #31 /lib64/libc.so.6(__libc_start_main+0x86) [0x1492279d9dc6]

Mar 12 15:47:49 Soundwave smbd[131285]: #32 /usr/sbin/smbd(_start+0x21) [0x5591b2eb1e61]

Mar 12 15:47:49 Soundwave smbd[131285]: [2026/03/12 15:47:49.663815, 0] ../../source3/lib/dumpcore.c:316(dump_core)

Mar 12 15:47:49 Soundwave smbd[131285]: dumping core in /var/log/samba/cores/smbd

Mar 12 15:47:49 Soundwave smbd[131285]:

I have a share called "YouTube" and I have it set in the Recycle Bin plugin to be an Excluded Share. Yet it is still creating the .Recycle.Bin folder. What do I have set wrong? I do not want to have the deleted files in this share to go into a recycle bin.

would be cool if the plugin would add a cli command to trash files

I just upgraded to 7.3.0 and the recycle bin plugin isn't catching any deleted files. Is this a known issue or do I need to do something different from previous versions? Thanks.

On 5/13/2026 at 10:32 PM, bobrap said:

I just upgraded to 7.3.0 and the recycle bin plugin isn't catching any deleted files. Is this a known issue or do I need to do something different from previous versions? Thanks.

Same issue here. 7.3.1 nothing works anymore.

Also somehow already at 7.2.7 the "Excluded Shares" only worked for me if one single share is set, if more excluded were set it created Recycle Bins for all shares.

On 5/13/2026 at 9:32 PM, bobrap said:

I just upgraded to 7.3.0 and the recycle bin plugin isn't catching any deleted files.

Please confirm if the files are not being moved to the Recycle Bin folder or just not showing in the trash/share stats

Appears to be working correctly for me, this is with 7.3.1

I am using this plugin a lot and i like it.

It would be great, if it would work with shares created by this plugin:

As far as I can see, this addon doesn't work. It creates the .Recycle.Bin folders in the SMB shares. But deleting files in those shares does not transfer the deleted files to the .Recycle.Bin folder. So there is no recycling bin functionality. Perhaps there's some random setting I missed but I also noticed that in the settings of this addon, no shares appear despite the fact that there indeed shares.

Edited August 4Aug 4 by DCCXVIII

Are you deleting them through samba? that's the only way it'll work, if you delete on the server itself it's completely bypassing that.

Edited August 4Aug 4 by Kilrah

3 hours ago, Kilrah said:

Are you deleting them through samba? that's the only way it'll work, if you delete on the server itself it's completely bypassing that.

I was deleting them via SMB from my Windows machine. I was basically creating test folders and text files, then deleting them, then checking the .Recycle.Bin folder and noticing that none of those deleted folders or text documents would appear in the .Recycle.Bin folder.

That being said, upon further testing, I figured out a very weird quirk of this plugin. It turns out that if you delete a folder or file of 0 bytes (like I was doing in order to test it), the deleted files are ignored by the plugin and completely bypass the .Recycle.Bin folder, thus resulting in no recoverability. However, if you added a e.g. single text character to a .txt file, saved it, then deleted it, THEN it would appear in the .Recycle.Bin folder.

So whoever designed this plugin has chosen to set it up in such a was as to completely ignore empty folders or files. Kind of weird, but there you go.

Edited August 5Aug 5 by DCCXVIII

On 1/18/2026 at 8:07 AM, dlandon said:

The current implementation of the recycle bin plugin does not set those recycle bin options. The %P should not have been used in the recycle bin plugin originally.

@dlandon , WDYM "the current implementation". The last release was 2025-03-16, well before you made this comment.

I had to uninstall the plugin, reluctantly, because my syslog was getting bombarded.

Can you recommend a definitive workaround to using %P?

1 hour ago, shooftie said:

The last release was 2025-03-16, well before you made this comment

Actually it’s 2025-11-18.

2 hours ago, shooftie said:

WDYM "the current implementation". The last release was 2025-03-16, well before you made this comment.

Maybe he means the New Next Programs Range https://github.com/dlandon/recycle.bin-next

@Revan335 , you're right. @dlandon reached out directly and put me on the right track. I'm now on the recycle.bin-next version and all seems to be working.

@wgstarks , you're showing the "Unassigned Devices" plugin. If you look at the version of the plugin listed on Unraid's CA apps, it is 2025.03.16.

Edited August 12Aug 12 by shooftie

So, until 6 days ago, the Recyle Bin was working just fine. All the deleting, scheduled delete, everything. Now, all of a sudden it does nothing. Tried a reinstall to no avail. No updates to anything or changes to the environment.

Any ideas as to what could be wrong and how to fix?

Thanks!!

8 hours ago, jmbailey2000 said:

Any ideas as to what could be wrong and how to fix?

Maybe if you post the diagnostics.