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 Reproducible: Always 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): [public] 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) Actual Results: 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. Expected Results: 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