Bug #2427

Greyhole upgrade to 0.13.1 (updated from 0.13.0)

Added by bigfoot65 about 2 months ago. Updated 17 days ago.

Target version:
Start date:
Due date:
% Done:



Upgrade Greyhole to version 0.13.0:

New features

- New command: greyhole --mv (beta; requires more testing) - Allows you to move data from one Greyhole share to another without copying the data through the Samba shares
- Detect and fix bitrot/silent errors; requires a new cron job; see near the end of USAGE file Fixes #199
- New command: greyhole --print-fsck : Print the fsck report for the last completed fsck task. This will print the same content that is sent by email when the --email-report option is used.
- Refactored FSCK report code; new layout for the 'all shares' fsck that runs weekly


- greyhole-dfree (used by Samba to calculate free space) should take into account the num_copies option of the share; i.e. real free space = 1 GB, num_copies = 4 => available free space on Samba share = 250 MB; also added -h parameter to greyhole-dfree executable Fixes #156
- Save recent log entries in DB; use that in greyhole --status Fixes #114; Fixes #102
- Allow restarting Samba & Greyhole when running in Docker
- Mention allow insecure wide links = yes as an alternative to unix extensions = no in USAGE file Ref: #192


- Correctly attribute write/close tasks; using the file handle (fd) was not enough; using the full path now
- When a write task is logged, and no opened-for-writing task is in the DB, create it! Fixes issue where Greyhole would think a file is closed without being written to, when that is not the case.
- When two spooled files (created by Samba VFS module) have the exact same modification time (to the microsecond!), ensure they are executed in the correct order: open, writes, close
- When running --fsck --disk-usage-report, correctly update 'parents' du_stats, when deleting the checked folder's du_stats
- --iostat was missing storage pool drives on un-numbered partitions (eg. whole-drive XFS partition on /dev/sdb); also added timestamps to output, updates are more frequent (5s instead of 10s), and sorted the storage pool drives in alphabetical order
- Correctly balance storage pool drives, when drive_selection_groups are configured: will balance the drives in each group amongst themselves only, instead of trying to balance all the drives together. Fixes #198
- greyhole --process-spool logged warnings because Metastore backups config was uninitialized
- If the Samba VFS symlink is missing/not working, and the expected target is also missing, download it from Github
- greyhole --logs should not watch both .log and .err, as .log will always contains all the same logs as .err
- Install script: ensure gnupg package is installed; it is required for apt-get add Fixes #227
- build_vfs script: try to install the required dependencies, before trying to build Ref: #223
- lsof file-locked check was not working in Docker (Alpine Linux), because -M flag is not available

Various code improvement & refactoring

- Removing old files; shellcheck; fixed white-space in shell scripts (was a mix of tabs and spaces)
- Updated .patch to Samba 4.11 & 4.12 VFS module (was not working on Alpine 3.11 & Alpine Edge - 3.12)
- WIP: VFS module for Samba 4.13 (untested)
- Simplified manual INSTALL instructions about Samba VFS module; just need the correct binary in the LIB dir; daemon will take care of created the required symlink pointing there
- Moved build-related files into build/ sub-directory
- Create new Docker images during build
- Faster re-building Samba VFS modules, on build servers

greyhole-0.12.3.png View (3.11 KB) bigfoot65, 06/14/2020 09:14 PM

greyhole-0.13.1.png View (3.6 KB) bigfoot65, 06/14/2020 09:14 PM

Capture.PNG View (3.21 KB) bigfoot65, 06/18/2020 09:33 PM

unnamed.png View (2.7 KB) bigfoot65, 06/18/2020 09:34 PM

GOOD.PNG View (2.91 KB) bigfoot65, 06/18/2020 09:38 PM


#1 Updated by cpg about 1 month ago

try it out please

#2 Updated by bigfoot65 about 1 month ago

Testing now on my HDA. Will let it run overnight and report results tomorrow.

I have automated backups that run, so should get a good idea if it's working correctly.

Will also run the checklist on it with a VM.

#3 Updated by bigfoot65 about 1 month ago

  • Status changed from New to Feedback

Tested on my HDA overnight and did not see any issues.

Now for the checklist, I ran it on a test VM and got the following:

1. Issues command greyhole-dfree and saw the following error

PHP Fatal error:  Uncaught Error: Class 'DaemonRunner' not found in /usr/share/greyhole/greyhole-dfree.php:3388
Stack trace:
#0 /usr/share/greyhole/greyhole-dfree.php(3375): Log::_log(4, 'PHP Warning [2]...', 'php_warning')
#1 /usr/share/greyhole/greyhole-dfree.php(5610): Log::warn('PHP Warning [2]...', 'php_warning')
#2 [internal function]: gh_error_handler(2, 'chdir(): No suc...', '/usr/share/grey...', 6307, Array)
#3 /usr/share/greyhole/greyhole-dfree.php(6307): chdir('')
#4 {main}
  thrown in /usr/share/greyhole/greyhole-dfree.php on line 3388
PHP Fatal error:  Uncaught Error: Class 'DaemonRunner' not found in /usr/share/greyhole/greyhole-dfree.php:3388
Stack trace:
#0 /usr/share/greyhole/greyhole-dfree.php(3378): Log::_log(3, 'PHP Fatal Error...', 'php_critical')
#1 /usr/share/greyhole/greyhole-dfree.php(5588): Log::error('PHP Fatal Error...', 'php_critical')
#2 [internal function]: gh_shutdown()
#3 {main}
  thrown in /usr/share/greyhole/greyhole-dfree.php on line 3388

2. Executed sudo ps guax | grep greyhole and output is as follows. Was not sure if this was correct.
root      1220  0.0  0.3  23708  3360 ?        S    09:52   0:00 /bin/bash /usr/bin/greyhole-php /usr/bin/greyhole --daemon
root      1236  0.1  2.6 278496 27044 ?        S    09:52   0:00 /usr/bin/php /usr/bin/greyhole --daemon
root      1486  0.0  0.3  11292  3080 ?        Ss   09:53   0:00 /bin/sh -c  /usr/bin/greyhole --process-spool --keepalive >/dev/null
root      1487  0.0  0.2  11292  3020 ?        S    09:53   0:00 /bin/bash /usr/bin/greyhole-php /usr/bin/greyhole --process-spool --keepalive
root      1493  0.1  2.6 278496 27176 ?        S    09:53   0:00 /usr/bin/php /usr/bin/greyhole --process-spool --keepalive
amahi     1652  0.0  0.1  10708  1032 pts/0    S+   09:53   0:00 grep --color=auto greyhole

All else appeared to work fine.

I downgraded amahi-greyhole to 0.12.3 and repeated the greyhole-defree command. It displayed the desired output with no errors.

Also checked the command on my HDA with the new version and got the same error. Downgrading it back to 0.12.3 yielded the same positive result with desired output as noted in the checklist.

Not sure what is causing the error, but it's obviously not ready for production.

#4 Updated by modem7 about 1 month ago

0.13.1 has been released with bugfixes.

Committed by error
Small fix for MySQL 8 Fixes #232
Prevent crash when trying to send a inexistant fsck log file by email
Bugfix: free space calculation was not working, in docker, if multiple mounts (-v) were defined for a storage pool drive, and 1+ folders inside it

#5 Updated by bigfoot65 about 1 month ago

  • Subject changed from Greyhole upgrade to 0.13.0 to Greyhole upgrade to 0.13.1 (updated from 0.13.0)

#6 Updated by cpg 30 days ago

  • Assignee changed from cpg to bigfoot65

Great job on catching the issues on 0.13.0. Available for testing:

#7 Updated by bigfoot65 30 days ago

  • Assignee changed from bigfoot65 to cpg

#8 Updated by bigfoot65 29 days ago

Same error as previous version with greyhole-dfree.

#9 Updated by cpg 29 days ago

Does it happen in "normal operation" of the daemon?

Or only when invoking the command greyhole-dfree?

The DaemonRunner class is defined in the greyhole php script per se and it appears to be invoked by greyhole-dfree in a (convoluted, in my view) manner.

#10 Updated by bigfoot65 28 days ago

I’ve only noticed it when running the command. I believe that command may run via a cron job periodically but not sure.

#11 Updated by cpg 26 days ago

  • Status changed from Feedback to Assigned

#12 Updated by bigfoot65 26 days ago

BTW, I initially removed this version from my HDA.

Decided to give it an extended test, so it's installed again.

Been running for 24+ hours and have not seen any problems.

The greyhole-dfree command error seems to be the only issue I've encountered.

#13 Updated by bigfoot65 25 days ago

I downgraded greyhole back to 0.12.3.

Attached are two pics, one with greyhole 0.13.1 and the other with the currently released Amahi version (0.12.3).

You will notice the disk space reported in my Windows share is messed up for 0.13.1.

I presume this is the result of the issue with greyhole-dfree.

#14 Updated by cpg 24 days ago

Yes, the USAGE file indicates there is supposed to be a line like this (in addition to vfs objects) to each share that uses GH

                    dfree command = /usr/bin/greyhole-dfree

and the man states this, so yes, it probably is harmless to ship with dfree being broken:

Greyhole  shares  defined  in  smb.conf include a custom dfree command that is used to return the total and available
       disk space in your Greyhole storage pool.  This allows Samba to report correct values to connected clients.

#15 Updated by bigfoot65 24 days ago

Both of those lines are in smb.conf for each share. I am using Greyhole-UI and it inserts those automatically I believe.

#16 Updated by modem7 24 days ago

Just as an fyi, 0.13.2 has been released with a minor crashfix patch.

#17 Updated by cpg 23 days ago

Thanks to both. The fix does not include anything related to dfree. I am looking at the code and it appears that the DaemonRunner class is not in it, but I have to research more.

#18 Updated by cpg 22 days ago

  • Status changed from Assigned to Feedback
  • Assignee changed from cpg to bigfoot65

please try

it has a patch that may work in a real greyhoel system. however, since my system is just a bare greyhole install, it does not appear to be broken, however, I am not sure if it works.

If it works, we can report it upstream. The patch is adding AbstractRunner and DaemonRunner classes to (from greyhole) to greyhole-dfree.php.

#19 Updated by bigfoot65 22 days ago

  • Assignee changed from bigfoot65 to cpg

I’ve installed it on my production server. Initial indication is that update fixed the issue.

greyhole-defree is now reporting the correct result.

9611081888 8082105700 1024

I will check it in the morning to see if there are any issues after the overnight fsck.

Will report back.

#20 Updated by modem7 22 days ago

v0.13.3 released w/ dfree fixes

#21 Updated by cpg 22 days ago

  • Assignee changed from cpg to bigfoot65

ready to test out with proper upstream fix:

#22 Updated by bigfoot65 22 days ago

  • Assignee changed from bigfoot65 to cpg

So there is another error now due to the recent patch :(

PHP Fatal error:  Cannot declare class DaemonRunner, because the name is already in use in /usr/share/greyhole/greyhole-dfree.php on line 7896

Greyhole Shares don’t report file size at all now.

#23 Updated by cpg 22 days ago

  • Assignee changed from cpg to bigfoot65

I screwed up and left my patch in for this release.

Please rpm -Uvh --force the same file, since I do not want to up the version.

#24 Updated by bigfoot65 22 days ago

  • Assignee changed from bigfoot65 to cpg


Updated and looks like that fixed it.

Awesome job!

#25 Updated by cpg 22 days ago

  • Status changed from Feedback to Closed

Released for Amahi 11, it will automatically update for users who have it already.

Thanks for all the testing and feedback!

#26 Updated by cpg 22 days ago

  • Status changed from Closed to Feedback
  • Assignee changed from cpg to bigfoot65

oops. getting reports that it does not show errors, however, it does not seem to actually work now.

This is from the man page:

       When greyhole-dfree is run, it will output three numbers.
       The first represent the total disk space, in blocks. The second represent the number of available blocks. The  third  value  is
       the block size, in bytes.

Maybe try this and report:

1) sudo greyhole-dfree PATH. or
2) cd PATH_TO_A_GH_SHARE; sudo sudo greyhole-dfree

$ cd /var/hda/files/movies; sudo greyhole-dfree
0 0 1024
$ sudo greyhole-dfree /var/hda/files/movies
0 0 1024

#27 Updated by bigfoot65 21 days ago

  • Assignee changed from bigfoot65 to cpg

This is what I got for the command:

sudo greyhole-dfree /var/hda/files/apollo
9611081888 2693765865.3333 1024

Looks right to me. Not sure why Windows doesn’t see it.

#28 Updated by bigfoot65 21 days ago

The drive mappings changed. Instead of reflecting NTFS, they are back to the negative numbers.

I've attached a screen shot. Not sure what's going on, but the version of Greyhole you patched worked fine.

When he made those changes, it seems like it didn't fix that issue. No error with greyhole-php, just messed up drive display in Windows.

I used the last RPM you posted in the bug report:

amahi-greyhole.x86_64                      0.13.3-1

#29 Updated by bigfoot65 21 days ago

Ok, now this is odd. I just checked again after posting the last update in the bug report and it's fine now.

I wonder if the negative numbers is occurring when greyhole is doing an fsck. Who knows, but now all seems ok.

Sorry for all the back and forth on this one.

#30 Updated by bigfoot65 21 days ago

Checked this morning after the overnight fsck and all appears fine.

Windows shares reflect correct numbers and no errors noted in the log.

Should be good to release this to the repo if you haven’t already done it.

Recommend closed out.

EDIT: FYI looks like 0.13.4 was released to round space reported which might have been the cause of the Windows issue. I will test once you have it ready.

#31 Updated by cpg 21 days ago

  • Assignee changed from cpg to bigfoot65

yeah, also this:

FYI, the free space reported by Greyhole now takes into account the number of file copies configured for the share.
So if you have 1TB free, and num_copies = 2, Greyhole will report 500GB free. 1TB was reported (before 0.13).

try this:

#32 Updated by bigfoot65 20 days ago

I have installed on my production HDA. No issues thus far, but will let it run overnight and report back.

#33 Updated by bigfoot65 20 days ago

  • Assignee changed from bigfoot65 to cpg

All looks good. Ready for release to repo.

#34 Updated by cpg 17 days ago

  • Status changed from Feedback to Closed

Released to the repos. Closing.

Also available in: Atom