SOLVED: --find-orphaned-files not working properly

[Bureaucromancer]

For some reason my greyhole --fsck --find-orphaned-files doesn't seem to be working. I copied a few tb of data into a previously tested pool (by way of the move LZ method) but then everything seems to have fallen apart when I moved the LZ back to /var/hda/files (everything was working properly at this point, and files were in the pooled drives).

I the first fsck I ran after moving the LZ's (and their contents) back produced huge numbers of "WARNING! No copies of this file are available in the Greyhole storage pool. " After that only the folders were visible in any of my shares. Running --find-orphaned-files runs, but only results in an fsck reporting that it is "entering" all the directories but doesn't do anything with them. I've manually gone into the gh folders of the pooled drives, and the files missing definitely all still exist, but seem to be completely invisible to greyhole itself and aren't appearing in their shares.

If it matters I'm running greyhole 0.9.29-1. I have tried setting all the permissions and ownerships of the of the shares and pooled drives, but with no effect on the outcome of an fsck.

PS: the thing that has me most worried right now is that there are actually a small number of files in seemingly random directories that HAVE appeared properly, but this isn't even full directories. A few random documents appear in a few folders, but by far the vast majority of files are only appearing by digging into the greyhole drives directly (and I have tried copying them somewhere accessible, these files ARE intact). I just can't get the symlinks to things to be recreated in the LZs (or understand why they got wiped in the first place, although some shouldn't exist, as the LZ got moved in SOME cases from an NTFS drive).

[bigfoot65]

You might consider upgrading to the latest version. I believe there were some issues with 0.9.29 and the most current is 0.9.31. Doing so might correct your problems.

[Bureaucromancer]

Update:
I spoke with some people on the Greyhole chat, and it looks like my problem isn't sticky_files = Music/storage_pool_directory = /var/hda/files/drives/drive1/gh, min_free: 10gb as such, but that there should ALSO be a storage_pool_directory = /var/hda/files/drives/drive2/gh, min_free: 10gb. Any reason that that line wouldn't be getting created even though the drive is selected as part of the storage pool?

Could I possibly get around this by just adding storage_pool_directory = /var/hda/files/drives/drive1/gh, min_free: 10gb to /var/hda/platform/html/config/greyhole.yml?

PS: I've experimented a bit more this just seems to be getting very odd. After briefly removing drive1 from my storage pool (in the web interface) and returning it, it's storage_pool line in greyhole.conf is as expected, but the line for drive2 has been REPLACED with a sticky_files music line.

-------------------------------

Original post:
That didn't fix it, but I have discovered something odd.

In my /etc/greyhole.conf one of my drives is listed only as

Code: Select all

sticky_files = Music/storage_pool_directory = /var/hda/files/drives/drive1/gh, min_free: 10gb

As far as I know this should be

Code: Select all

storage_pool_directory = /var/hda/files/drives/drive2/gh, min_free: 10gb

It seems that what's happening IS that any files on that drive aren't being handled properly. I haven't done anything to activate sticky_files in my Music share and when I went into that share in my HDA web interface I found that in the tag box there is a "music" entry separate from the "Music" created in the check box, and which get restored when I remove it.

Would it perhaps be reasonable to kill the music share, copy it's files out of the gh folders manually and restore it in the hopes that it will fix my drive1? Any ideas on what might be going on here?

PS: After some fiddling I may have been imagining the problems with the tags entry, but the sticky files thing is still there.

PPS: I've found that music is sticky by default for amahi_tunes, and have now turned off the music tag on the share (now untagged completely). Still experiencing the problem.

[Bureaucromancer]

Not sure if this will be helpful, but I thought it might be, and I am wondering if it might be missing something, so here goes.

My greyhole.yml is below:

Code: Select all

# Greyhole default settings # # Note: if you make changes to this file and they do not appear # in the greyhole.conf, please double check the formatting. To # test the parsing of this file do: # # echo 'require "yaml"; YAML::load(File.open("greyhole.yml"))' | irb # # db_engine: sqlite or mysql db_engine: mysql # options for sqlite db engine db_path: /var/cache/greyhole.sqlite # options for mysql db engine db_name: greyhole db_user: greyhole db_pass: greyhole db_host: localhost # other defaults: email_to: root greyhole_log_file: /var/log/greyhole.log log_level: DEBUG log_memory_usage: no dir_selection_algorithm: most_available_space df_cache_time: 15 delete_moves_to_attic: yes balance_modified_files: no

[bigfoot65]

Mine looks pretty much the same except there is sticky files entry for Music. Not sure why as I don't have Amahi Tunes or DLNA installed.

This is the default file when Amahi is installed I believe.
https://github.com/amahi/platform/blob/ ... eyhole.yml

Not sure what could be causing the issue. This look like one that may need answered by gboudreau.

[Bureaucromancer]

Spoke with gboudreau briefly in chat, no real quick solution but he suggested there might be a problem with a line feed ending in the .yml, so just nuked my yml and replaced it with the example. Things actually seem to be working now, though I've got a pretty long fsck to run before I can confirm.

[bigfoot65]

Hope this fixed your problem.

[Bureaucromancer]

Looks like everything's good (though for the record, full fsck's of a multi terabyte filesystem are NOT fun to wait for ).

[bigfoot65]

Glad to hear it all looks back to normal. Linux is so picky on parsing text files.