recycle:keeptree = yes
recycle:versions = yes
recycle:touch = yes
recycle:touch_mtime = yes
recycle:exclude = ?~$*,~$*,*.tmp,*.temp,*.TMP
recycle:repository = _recycle
recycle:directory_mode = 0777
recycle:maxsize = 536870912
path = /mnt/data/data
vfs objects = recycle
recycle:repository = Tmp/_recycle/_recycle.%u
/mnt/data/daten contains it's own data + a subdir "projects" which is a different mount from a different device.
Deleting from any subdir and depth of the main partition works, deleting from "projects" results in the directory structure being created, but no deleted file appearing. There is no error in any log file after this at log level = 1.
I guess it may be using rename(2) or something similar for performance reasons and that may not work inter-device. I don't know why there is no logged error though (at level 1).
At level 3, I think the problem is apparent:
[2011/11/30 04:05:53.811158, 3] modules/vfs_recycle.c:646(recycle_unlink)
recycle: Move error 18 (Invalid cross-device link), purging file XXX (Tmp/_recycle/_recycle.YYY/XXX)
I guess the ", 3" means it's a level 3 msg. I don't know why such an error message is only available at level 3, because level 3 already includes lots of misc. output making it kind of hard to see this error amidst all the messages.
Not a blocker I'm afraid - this would be an enhancement to how the vfs_recycle works.
What is needed here is a background process to do the copy whilst the reply to the unlink is deferred.
How is it not a blocker when the basic functionality is not working (file is not recycled) and no user visible error is produced? A user would expect this to work.
At least critical would apply (loss of data).
Also, as a quick fix/workaround, could you just use simple move or copy/delete logic if the code path fails?
This comes under the "admin should know better" case. Not the users problem, the admin should have arranged the storage more intelligently.
I think this could be a problem for many samba-sites.
So with one of my samba servers. That run continuously for 220 days.
Now i updated to version 3.6.5 and recycle was broken for me.
I didn't realize it. A user informed me that deleted files doesn't appear in the bin.
It worked before. What was the reason to change the old behaviour?
Shouldn't there be no waring in the release notes?
Does the "crossrename" vfs module after the recycle module fixes this?
vfs objects = recycle crossrename
"crossrename" vfs module helps, but now there is no any records about renaming or deletion in log (using full_audit).
Now I can't see if user deleted the file.
Just found that I hit this bug ( and this is really bug because behaviour was changed without any notice ) when redhat released 3.6 for rhel.
And man page still have nothing about this.
Is it possible to update documentation at least?
So "admin should know better" will be true? ;-)
btw, I think it is better to revert back expected behaviour.
just upgraded from debian squeeze to wheezy and hit this annoying bug.
why annoying ? because in the previous version this worked !!
i see that this is also an old bug (2 years ago).
luckily adding the "crossrename" has helped and i dont' need
the audit but i don't understand why change the previous behaviour
when you can add another parameter or create a different modules (recycle_fast ?)
with the "link" instead of the "file copy".
I understand that with the hard link (vs the file copy) you gain in performance but as already told by other, this don't work across different file systems and the fact that the path is created but the file is missing is a sneaky bug !
To give this a little more input, I've got the same problem here on a wheezy driven server now but without this directories spreaded over different filesystems. In my case there is only ONE filesystem but on a btrfs filesystem which spans two disks at the moment. The funny thing, the recyler works within user homes on the same filesystem. Only shared recycler for group directories has the described issue.
Awaiting to be fixed.
I just found out the hard way that my recycle bin no longer works... :-(
Adding the crossrename helped but as already stated this inhibit the audit logs.
We would appreciate to having this feature enable in the next patch cycle.
I used to store the trash bin on a different device for several reasons, and that's really annoying.
With vfs objects = recycle crossrename it can do the trick for small files, but on bigger files, exactly the same problem.
I hop it'll be fixed on the next update.
On 2014-01-27 at 22:37 +0000 email@example.com sent off:
> With vfs objects = recycle crossrename it can do the trick for small files, but
> on bigger files, exactly the same problem.
see man page of vfs_crossrename how to modify the size of files that the
crossrename module will handle
I agree this is critical and not an enhancement, since there is data loss. And the "admin *could* know this better" if it were documented somewhere. It seems intelligent to me to move what may be garbage (the user is deleting, so may be garbage) out of my expensive SAS drives to cheap SATA ones. And this bug status should also be changed to "OLD" instead of "NEW".
Now that I've protested and feel relieved, to the constructive side :)
Use crossrename may be a workaround, but not a solution, this behavior should be adjustable and better documented on vfs_recycle man page/wiki.
*** Bug 10666 has been marked as a duplicate of this bug. ***
It's almost 10 years without progress, but I still would like to add some related facts, because I've just setup new NAS with samba 4.10.7 (ubuntu) and hit this bug. ZFS is more popular nowadays and will be probably used more and more, so samba should handle this (at least some way).
- Not using multiple ZFS datasets, but they are really useful in terms of backups...
- Not using "global" samba share over multiple ZFS datasets. But this is also useful for managing files of other people or just when having many ZFS datasets.
- Use vfs_crossrename with high sizelimit. (example below)
- Fix vfs_recycle to do "crossrename functionality" itself
- Fix vfs_recycle to do "move" on the background, but not sure how safe it is.
But even without fix, vfs_recycle should write error into log and add note into man page, because this is data loss.
I'm also little confused, because vfs_crossrename is advertised to do move between filesystems, but samba (at least 4.10.7) is able to move files even without vfs_crossrename.
My config to handle this
# recycle and crossrename set to 100 GiB
# not using single recycle for all shares to prevent slow moving between ZFS datasets for regular shares
vfs objects = recycle crossrename
crossrename:sizelimit = 102400
recycle:repository = .recycle
recycle:maxsize = 107374182400