3 minutes ago, AdmiralSpeedy said:

I have an array with a single SSD as a cache pool. I thought it might have something do with that as well, but I did try deleting an old file that was on the array and not something I just created to test that would still be on the cache pool.

Post diagnostics.

On 2025/12/21 at PM11点55分, dlandon said:

有,但是这个分叉插件无法解决这个问题。此分叉插件添加了 Unraid 已经管理的水果配置 - 当不需要时,可能会添加两次:
[等值线]

可浏览 = 否

评论 = ISO 图像

路径 = /mnt/user/isos

有效用户=*********

否决文件 = /。回收箱

vfs 对象 = 卡蒂亚水果流_xattr 卡蒂亚水果流_xattr 回收 <= 水果可能添加两次

写列表 = *********

回收:exclude_dir ="。Recycle。Bin”

回收:排除 = *.tmp

回收:版本 = 是

回收:最小尺寸 = 1

回收:touch_mtime = 否

回收:触摸 = 是

回收:keeptree = 是

回收:目录_模式 = 0777

回收:存储库 = 。回收箱

水果:编码=本地

此插件将“/etc/samba/smb-fruit。conf”额外设置添加到共享配置中,无论 “增强 macOS 互操作性:” 环境。如果设置为“是”,则此插件会第二次添加额外的设置,从而导致重复的 vfs_objects。这是一种不适当的桑巴配置,可能会导致冗余操作和问题。该插件似乎没有对共享配置进行任何其他更改,因此不清楚“修复”了什么。如果添加这些 vfs_objects 似乎可以修复 samba 故障,那么这只是一个侥幸,因为这不是解决方案。

问题在于 samba 如何处理存储库。旧版本的桑巴舞对不适当的配置设置更加宽容一些。较新版本的 samba 对配置设置更加严格。

我不鼓励使用这个分叉插件,因为它对解决问题没有任何作用,而且实际上可能会导致问题。

At the beginning, my initial tests showed no issues. Later, I found that the problem is very random. I originally thought it was caused by the fruit configuration, but later I realized that my changes did not actually resolve the issue.😭😭😭

I added fruit:aapl = no to the global configuration, and the errors seem to occur much less frequently, but there are still a lot of errors in the logs. This issue appears to be an upstream Samba problem, and the only option is to wait for an update.

On 12/21/2025 at 11:55 PM, dlandon said:

There is, but it is not addressed by this forked plugin. This forked plugin adds the fruit config that is already managed by Unraid - when not needed and potentially twice:
[isos]

browseable = No

comment = ISO images

path = /mnt/user/isos

valid users = *********

veto files = /.Recycle.Bin

vfs objects = catia fruit streams_xattr catia fruit streams_xattr recycle <= fruit potentially added twice

write list = *********

recycle:exclude_dir = ".Recycle.Bin"

recycle:exclude = *.tmp

recycle:versions = Yes

recycle:minsize = 1

recycle:touch_mtime = No

recycle:touch = Yes

recycle:keeptree = Yes

recycle:directory_mode = 0777

recycle:repository = .Recycle.Bin

fruit:encoding = native

This plugin adds the "/etc/samba/smb-fruit.conf" extra settings to the share configuration regardless of the "Enhanced macOS interoperability:" setting. If it is set to "Yes", this plugin adds the extra settings a second time resulting in duplicate vfs_objects. This is an inappropriate samba configuration and could result in redundant operations and issues. There don't seem to be any other changes made by this plugin to the share configuration, so it's unclear as to what's been "fixed". If having those vfs_objects added appears to fix the samba fault, it is a fluke because that is not the solution.

The issue is in how samba handles the repository. The older versions of samba were a bit more tolerant of inappropriate confiuguration settings. The newer versions of samba are stricter about the configuration settings.

I discourage the use of this forked plugin as it does nothing to address the issue amd may in fact cause problems.

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

Edited January 16Jan 16 by bigfoxtail

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: