This case appears to be a non-standard (to say the least) use of the "Trash" function. In addition to the possible network and mounting permissions, file locking, and ownership issues, I am not entirely certain that this case falls under the intended scope of the current implementation of the 'Trash' feature (but don't quote me on that - I could be wrong). In my understanding, 'Trash' is intended only to handle one's personal files ($HOME) on a single OS (in this case: localhost2, since that is your current running OS). You could of course simply move (via cut-and-paste) the file(s) to your ~/.Trash/.. folder on either filesystem (assuming permissions are correct), but then this would effectively bypass the 'Trash' feature completely, and leave no restore index entry.
If you are certain that all network, mounting, permissions, file locking, and ownership considerations are in order, then I would have to conclude that Nautilus (?) file browser and/or 'Trash' feature are simply not capable of dealing with a file(s) physically located on a "remote" (networked, not local) partition. I can see how the absence of the target filesystem (un-mounted, or network down) would make recovery impossible, blowing Nautilus' little mind.
If someone with more knowledge and experience can enlighten on this, I hope they do so.