Making GH play nice with Open Media Vault

[old-square-eyes]

Former Amahi user with manual GH install.

I finally got GH up and running on Open Media Vault, with a manual install - and I'm loving OMV so far. I noticed these issues with GH...

1. Samba GH settings are overwritten by OMV, at least on creating/editing a samba share, but possibly at other times.
2. GH runs only on fsk - DEBUG sleep: Nothing to do... Sleeping. When new files are added to share.
3. After fsk, files disappear in samba share, though I do see "Creating symlink in share" in logs. GH makes copies correctly to pool drives. Somehow the symlinks aren't propagating/shown.
4. OMV Mounts in Linux the improper way. i.e. "Bad" example from https://github.com/gboudreau/Greyhole/wiki/AddStoragePoolDrive#best-practices-for-mounting-partitions

Would love these two awesome apps to coexist :)

[gboudreau]

You'll have to check this with the OMV people. Not much I can do if OMV overwrites the config you added manually...
They had a Greyhole plugin a while ago, but I guess it's not maintained anymore. Not sure if it would help, if the OMV core overwrites what you added in the smb.conf file, I would guess it would do the same with the plugins-added config.

[old-square-eyes]

Fair point. Thanks for the quick reply. I love GH by the way!

Any thoughts on 2 & 3?

For 4... I'm wondering if I should mount GH file systems outside of OMV. Then use OMV for non pooled shares and landing zone.

[gboudreau]

2 & 3. are probably related to 1. I would guess something is missing from your smb.conf for Greyhole to work as expected. Re-check USAGE guide, and ensure all the entries needed in smb.conf are there, and restart samba, and try again.

4. is OMV-related. If they want to fix it, they could. But it shouldn't be a problem, as long as your drives don't change /dev/sdX identifier, which normally only happens if you change where those drives are connected.

[old-square-eyes]

OK thanks. Have floated these as ideas https://forum.openmediavault.org/index.php?thread/32010-greyhole-manual-install-not-playing-nice/

[old-square-eyes]

Some progress over there... turns out share definitions can be passed as parameters in OMV. The global ones work, as does dfree command = /usr/bin/greyhole-dfree under shares. However, the samba share breaks (becomes inaccessible, while still visible on the network), when vfs objects = greyhole is added too.

[old-square-eyes]

Doesn't appear to be syntax or delimiters as the following works for the global section...

[old-square-eyes]

Here is my whole samba config, as written by OMV (photos lists contents and is browsable, videos is available, but un-browsable)

GNU nano 3.2 /etc/samba/smb.conf

#This file is auto-generated by openmediavault (https://www.openmediavault.org)
#WARNING: Do not edit this file, your changes will get lost.
#======================= Global Settings =======================
[global]
workgroup = DAN
server string = %h server
dns proxy = no
log level = 0
log file = /var/log/samba/log.%m
max log size = 1000
logging = syslog
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = no
unix password sync = no
passwd program = /usr/bin/passwd %u
passwd chat = Enter\snew\s\spassword:* %n\n Retype\snew\s\spassword:* %n\n *password\supdated\ssucces$
pam password change = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
guest account = nobody
load printers = no
disable spoolss = yes
printing = bsd
printcap name = /dev/null
unix extensions = yes
wide links = no
create mask = 0777
directory mask = 0777
use sendfile = yes
aio read size = 16384
aio write size = 16384
time server = no
wins support = yes
multicast dns register = no
#Special configuration for Apple's Time Machine
fruit:aapl = yes
#Extra options
unix extensions = no
wide links = yes

#======================= Share Definitions =======================
[videos]
path = /srv/dev-disk-by-label-landing/videos/
guest ok = no
guest only = no
read only = no
browseable = yes
inherit acls = yes
inherit permissions = no
ea support = no
store dos attributes = no
vfs objects =
printable = no
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
hide special files = yes
follow symlinks = yes
hide dot files = yes
valid users = "square_eyes"
invalid users =
read list =
write list = "square_eyes"
dfree command = /usr/bin/greyhole-dfree
vfs objects = greyhole

[photos]
path = /srv/dev-disk-by-label-landing/photos/
guest ok = no
guest only = no
read only = no
browseable = yes
inherit acls = yes
inherit permissions = no
ea support = no
store dos attributes = no
vfs objects =
printable = no
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
hide special files = yes
follow symlinks = yes
hide dot files = yes
valid users = "square_eyes"
invalid users =
read list =
write list = "square_eyes"
dfree command = /usr/bin/greyhole-dfree

[old-square-eyes]

Samba logs full of WARNING: "wide links" enabled. You might need to modify the smbd apparmor profile manually.

[gboudreau]

Shares becoming inaccessible when you add vfs objects = greyhole means the Greyhole VFS module is not working. Check the greyhole log (/var/log/greyhole.log), just after restarting the Greyhole daemon.
You might need to recompile your own version of the VFS, per the instructions in greyhole.log

Wide-link are indeed required by Greyhole, and not having it enabled will make the symlink broken or invisible on you shares, once greyhole moved the file copies onto a storage drive, and replaced it with a symlink. That AppArmor warning is probably what you should look into.
I'm not using AppArmor, but maybe the OMV guys know how to allow Samba to access other folders in the AppArmor configuration. Ref: https://bugzilla.novell.com/show_bug.cgi?id=783719#c3

[old-square-eyes]

This is what I have following a Daemon kick off. Looks ominous. I have really struggled to run the install script from my other issue. I had to settle for a manual install. But I have seen the fsk work.

Apr 18 13:19:22 WARN daemon: PHP Warning [2]: symlink(): No such file or directory in /usr/bin/greyhole on line 5131; BT: greyhole[L7347] run() => greyhole[L7314] initialize() => greyhole[L7336] samba_check_vfs() => greyhole[L4170] gh_symlink(/usr/lib64/greyhole/greyhole-samba49.so,/usr/lib/x86_64-linux-gnu/samba/vfs/greyhole.so) => greyhole[L5131] symlink(/usr/lib64/greyhole/greyhole-samba49.so,/usr/lib/x86_64-linux-gnu/samba/vfs/greyhole.so)
Apr 18 13:19:22 INFO daemon: The Samba daemon will now restart...
Apr 18 13:22:29 INFO fsck: Cleaning executed tasks: keeping the last 60 days of logs.
Apr 18 13:51:23 INFO daemon: Greyhole (version 0.12.3) daemon started.
Apr 18 13:51:23 INFO daemon: Checking MySQL tables...
Apr 18 13:51:23 DEBUG daemon: Loading metadata store backup directories...
Apr 18 13:51:23 DEBUG daemon:   Found 2 directories in the settings table.
Apr 18 13:51:23 DEBUG daemon: Checking symlink at /usr/lib/x86_64-linux-gnu/samba/vfs/greyhole.so...
Apr 18 13:51:23 WARN daemon:   Greyhole VFS module for Samba was missing, or the wrong version for your Samba. It will now be replaced with a symlink to /usr/lib64/greyhole/greyhole-samba49.so
Apr 18 13:51:23 WARN daemon: PHP Warning [2]: symlink(): No such file or directory in /usr/bin/greyhole on line 5131; BT: greyhole[L7347] run() => greyhole[L7314] initialize() => greyhole[L7336] samba_check_vfs() => greyhole[L4170] gh_symlink(/usr/lib64/greyhole/greyhole-samba49.so,/usr/lib/x86_64-linux-gnu/samba/vfs/greyhole.so) => greyhole[L5131] symlink(/usr/lib64/greyhole/greyhole-samba49.so,/usr/lib/x86_64-linux-gnu/samba/vfs/greyhole.so)
Apr 18 13:51:23 INFO daemon: The Samba daemon will now restart...
Apr 18 13:51:24 INFO fsck: Now working on task ID 1246: fsck /srv/dev-disk-by-label-landing/videos/
Apr 18 13:51:24 INFO fsck: Starting fsck for /srv/dev-disk-by-label-landing/videos
Apr 18 13:51:24 DEBUG fsck:   Storage volume? No
Apr 18 13:51:24 DEBUG fsck:   Share? videos
Apr 18 13:51:24 DEBUG fsck: Entering /srv/dev-disk-by-label-landing/videos
Apr 18 13:51:24 DEBUG fsck:   Scan metadata stores? No
Apr 18 13:51:24 INFO fsck: fsck for /srv/dev-disk-by-label-landing/videos completed.
Apr 18 13:51:24 INFO fsck: Completed 1/2 fsck tasks.
Apr 18 13:51:24 INFO fsck: Now working on task ID 1247: fsck /srv/dev-disk-by-label-landing/photos/
Apr 18 13:51:24 INFO fsck: Skipping fsck; --if-conf-changed was specified, and the configuration file didn't change since the last fsck.
Apr 18 13:51:24 DEBUG sleep: Nothing to do... Sleeping.

[gboudreau]

You are missing the /usr/lib64/greyhole/greyhole-samba49.so file.

sudo mkdir -p /usr/lib64/greyhole/
sudo curl -Lo /usr/lib64/greyhole/greyhole-samba49.so https://github.com/gboudreau/Greyhole/raw/master/samba-module/bin/4.9/greyhole-x86_64.so

Then restart the daemon, and check the logs again.
If that module is not working, it will tell you, and ask you to run a build_vfs command.

[old-square-eyes]

Samba is up on my network and I can browse shares... and Greyhole appears to be making copies, after I was able to re-run the install script per #227

Not too sure what about my manual install wasn't right. But just pleased it's working.

Edit: Just saw your previous post. Possible I messed up the manual install then :/

[old-square-eyes]

I might as well post here as it's really a follow up question on the same topic. I mounted my shares locally for gh (referenced in /etc/greyhole.conf, using the Amahi naming convention for convenience). However, while everything works for gh I see mount errors for the same drives, which are also mounted in OMV. I feel the mounting happening with fstab for gh is somehow conflicting or creating a race condition at boot that OMV doesn't like. I suspect it's a race condition because it only happens to the second gh drive (the first currently also houses my samba shares if that's relevant).

I'm no Linux pro, so what I have tried might even be sacrilegious. OMV is very clear about only using OMV to mount filesystems. Though they mount by name, and not by-uuid.

My question is: Can I reference the OMV mount in the gh config, and do away with the gh fstab entries altogether?

Like so...

I have tried this just now, and all seems to work with no errors in OMV or gh, which is hapily making copies to my pool drives. But I don't want to put the ongoing gh operations at risk.

I guess if that's not going to be OK for gh, then I could also forget even mounting the gh drives at all in OMV and let gh work away in the background on a dedicated landing zone that I set up and mount from OMV.

[gboudreau]

It doesn't matter how your storage drives are mounted. Just refer to the path to the drivers in your greyhole config. So you can let OMV mount the drives.