The vfs_recycle of samba-3.6 is broken when the recycle repository is configured to a different mount point than the network share. It silently fails - only directory structure is created but the files are not moved the recycle repository.
I found this after upgrading from amd64 stable samba-3.5.15 to the stable samba-3.6.9, same config. Reverting to samba-3.5.15 fix the issue.
I found this reported upstream as well: https://bugzilla.samba.org/show_bug.cgi?id=8637
Steps to Reproduce:
1. Configure vfs_recycle repository to a different mount point than the network share.
2. Example config (working for samba-3.5.15 and broken for 3.6.9):
path = /var/samba/public
public = yes
writable = yes
vfs objects = recycle
recycle:keeptree = yes
recycle:versions = yes
recycle:repository = /var/samba/trash/%S
Where /var/samba/public and /var/samba/trash are different mount points. For example:
# mount | grep smb
/dev/vg/smb-public on /var/samba/public type ext4 (rw,nosuid,noexec,noatime)
/dev/vg/smb-trash on /var/samba/trash type ext4 (rw,nosuid,noexec,noatime)
On samba-3.6.9, when a file is removed from a network share, the vfs_recycle silently fails and the removed file is not moved to the bin.
It should work as it works on samba-3.5.15, a removed file from a network share is moved to the recycle bin.
I classify the severity of this as critical, since I lost production data: an important folder deleted by accident by an user -- exactly the kind of situation this feature was designed to protect us from -- everything that changed since the last backup was lost and should have gone to the recycle bin instead.
With this bug open I don't this version should be marked stable on portage.
Please reopen if this still affects current samba-4.x versions