The Samba-Bugzilla – Bug 8637
vfs_recycle move to different partition/mount (cross-device move) "silently" fails (creates only directory, but no recycled file)
Last modified: 2014-06-24 07:00:48 UTC
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. ***