You can run an fsck with the --find-orphaned-files option which is made to find files in the gh folder which do not have tombstones.

The trash share doesn't actually contain files, only symlinks. So you can put it anywhere without fear of taking up space. The actual files reside in the attic locations on the pool drives where the files originally resided, these are what the trash share symlinks point to.

1. I'm not sure what you mean by files that you moved around are in the trash. When you deleted the tombstones and ran an fsck with the option to find orphaned files it creates tombstones for the files where and how they are in the pool directories. It will not sending anything to the trash, not unl...

I'm skeptical that Greyhole is creating these files. It seems more likely that something wrote the files that way and Greyhole is just reflecting what was written to the share. What makes you think otherwise? Something in the Greyhole logs?

As radioz said, post the output of `df -h` and that'll give us an idea of what/where exactly /dev/sdb is mounted to (I'm assuming it's a pool drive -- but we should verify this). If it is a pool drive, can you actually cd to the mounted path and look at it? If you can't read from the drive Greyhole ...

What do you see if you look at the actual landing zone on your server? Are they symlinking to different files or the same files?

The database doesn't maintain state information, really. That all resides in configs and graveyards. You could try to do a --going on sdb, but if the drive is already in a state where the system can't read from it (I'm assuming that's the case -- you'd know better than I, having access to the system...

The OS may be important here. I haven't experienced this issue myself, but I found the following things with a quick google search: http://us.generation-nt.com/answer/samba-newly-created-files-folders-showing-up-only-i-change-folders-come-back-help-200648781.html http://social.technet.microsoft.com/...

As root you can run `blkid -L` and this will spit out the drive, filesystem type, mount point, and UUID, that should give tell you which drive has the LZ partition.

I'm assuming that - if checking the file directly on server and it is available in the /var/hda/files/Movies/Movie1/movie1.mkv as symbolic link to /var/hda/files/drives/drive1/gh/Movies//movie1.mkv Should actually read - if checking the file directly on server and it is available in the /var/hda/fil...