after disabling BTRFS check, i'm still getting those daily cron emails -
[snip]
Yep, exactly the same here. Also this morning a separate mail (this one from cron.weekly rather than cron.daily) with:
/etc/cron.weekly/openmediavault-scrub_btrfs:
Performing a scrub on Btrfs file systems.
/etc/cron.weekly/openmediavault-update-smart-drivedb:
Updating smartmontools drive database.I'm fairly sure I've only been seeing these since updating to 6.3.5.
Yes, it would be interesting to know quite what caused the issue, but I suspect the answer is "me". I have a vague recollection that I had a warning some while ago about grub and that I followed a recommendation to address that. Unfortunately I don't seem to have made any notes about it at the time and I don't know if there's a way to find such things in the various logs.
No worries, and certainly don't go mucking about with snapshots.
For what it's worth, I eventually killed the apt process (I had been using pkill <pid> when it should of course have been kill <pid> or pkill apt - oops!). When I then tried to use apt it said that a manual dpkg --configure -a was required - which took me back into the grub-pc install loop again! I gave up and allowed it to proceed this time (on /dev/sda). It produced:
Found linux image: /boot/vmlinuz-6.0.0-0.deb11.2-amd64
Found initrd image: /boot/initrd.img-6.0.0-0.deb11.2-amd64
Found linux image: /boot/vmlinuz-5.19.0-0.deb11.2-amd64
Found initrd image: /boot/initrd.img-5.19.0-0.deb11.2-amd64
Found linux image: /boot/vmlinuz-5.18.0-0.deb11.4-amd64
Found initrd image: /boot/initrd.img-5.18.0-0.deb11.4-amd64
doneA subsequent /usr/bin/apt-get dist-upgrade -d -y -o APT::Get::Show-Upgraded=true produced no errors or warnings, and the when I rebooted the system it came up again with no warnings or signs of any problems. Hopefully that's it sorted.
Thanks for your input.
Thanks, I gave that a try (at my own risk, with warnings duly noted).
- Step 1 (remove grub-pc) went OK.
- Step 2 (proceed with updates) did nothing as the web UI reported nothing to do (also tried /usr/bin/apt-get dist-upgrade -d -y -o APT::Get::Show-Upgraded=true from the command line as that seems to be what the web UI executes - that just reports 0 upgraded/installed/removed and that grub-pc-bin grub2-common are no longer required and can be autoremoved).
- Step 3 (reinstall grub-pc) failed. It gives the messages:
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for cross-disk install.... and then enters a character-based menu system to provide options. Unfortunately the "Continue? NO" option doesn't seem to work, and I can't find a way to break out of it (tried ctl-C, and pkill <pid-of 'apt install grub-pc'> from another terminal). Keeps looping around, with choices:
GRUB install devices: │
│ │
│ [*] /dev/sda (2199023 MB; Virtual_disk) │
│ [ ] /dev/sdb (26843 MB; Virtual_disk) │
│ [ ] /dev/sdb1 (25818 MB; Virtual_disk)Not sure what best to do from here...
The APT update procedure has started reporting a problem with grub-pc while trying to upgrade containerd.io on my OMV6 instance. I've found a few variations on this sort if thing in here and elsewhere but I don't know enough about grub to tinker without some guidance. The reports include the following, trimmed for clarity and hopefully without cutting anything important:
The following packages will be upgraded: containerd.io
[...]
Setting up grub-pc (2.06-3~deb11u4) ...
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for cross-disk install.
You must correct your GRUB install devices before proceeding:
DEBIAN_FRONTEND=dialog dpkg --configure grub-pc dpkg --configure -a
dpkg: error processing package grub-pc (--configure): installed grub-pc package post-installation script subprocess returned error exit status 1
Errors were encountered while processing: grub-pcPresumably I've broken something at some point. Some of the threads I've seen regarding grub-pc issues have questions about whether or not the system is UEFI. Mine is an ESXi Virtual Machine and I'm not sure how to check without booting it into BIOS (can do if necessary) but there's no efi directory under /sys/firmware if that helps. [edit] Found the boot options for the VM and it is indeed set to BIOS.
Thanks, will take a look at those plugins and see if I can figure out how they tick. I don't know anything about saltstack but I'm familiar with the others to varying degrees.
That guide will help with everything but the web interface side on OMV 6.x. Looking at other plugins is the best way to learn. I can answer questions as well. What kind of plugin(s) were thinking about?
OK, thanks. I don't have anything particular in mind, it's little more than curiosity at the moment - wondering what sort of things are possible, how difficult it is and what skills are needed. Any suggestions for a suitable existing to use as the basis for some sort of "Hello World" plugin?
It wouldn't be hard to change but it would break existing installs.
Understood - I'm not asking for a change.
I think these directories are created by a document library system called Calibre, it's a while since I touched it. Its naming scheme might be configurable but, as I said, I was just using this collection of files and directories for test purposes, I can easily use something else for that. I was hoping there might be some convention for coping with embedded commas, or configurable separators or something, in case it ever comes up as a real world requirement. Probably not very likely though, so no worries.
By the way, are there any tutorials or on creating plugins that you'd recommend? I found this guide but it targets a very old version of OMV. I remember reading that converting plugins for successive versions can be quite involved so I wouldn't be surprised if that guide is quite out of date.
Unfortunately the names in question are automatically generated. I could edit the generated script manually, but that would of course get overwritten with any changes made in the (very convenient) UI. Not a major issue in this case, it was only some directories I was using for test purposes. Thought I'd ask in case it crops up anywhere else.
Thanks for responding so promptly.
Quick question: This plugin [edit: on OMV6] uses commas to separate directory names to include/exclude. How do we specify names that contain embedded commas? I've tried wrapping them in single or double quotes, and escaping the comma with a backslash, but in each case the generated copnfiguration file ends up splitting on the embedded comma.
Hope that description makes sense.
I haven't managed to find the cause of the difference in the openmediavault-webgui config files between my two OMV6 machines, as they both seem to have IPv6 disabled. I did however solve the problem that the dropping of "ipv6only=off" was causing me.
My server blocks previously only had IPv6-style "listen" directives such as:
listen [::]:80;
listen [::]:443;It wasn't necessary for the blocks to use IPv4-style listen directives because, if I understand correctly, nginx automatically listened for the corresponding IPv4 addresses. That presumably only applies when the "ipv6only=off" directive was present on the default server though. On OMV6, which doesn't seem to use ipv6only=off, the OMV web UI was being served in place of my sites on OMV6, i.e. regardless of the hostname specified in the request. Explicitly adding IPv4 "listen" directives to each of my other server blocks worked for me:
listen 80;
listen 443;
listen [::]:80;
listen [::]:443;Hope this might help anyone else landing here with a similar problem.
one of your system has IPv6 enabled and the other not.
As far as I can see from the web UIs they all have IPv6 disabled. My OMV5 system shows:
My main OMV6 system (the one that has "listen *:80 default_server" and so on) shows:
... and my test OMV6 system (the one that has "listen 80 default_server") shows:
I've hosted my own websites alongside OpenMediaVault for some time now, first using the nginx plugin on OMV4 and then with plain config files on OMV5. I'm now looking at v6 (great job by the way, very slick) and although I've got things working there I'm a bit puzzled by the differences I'm seeing. These differences are not just between v6 and v5, but also between two v6 installs that I thought I had configured similarly. Presumably there's more going on behind the scenes than I realised.
In OMV5 the openmediavault-webgui config file contains:
listen [::]:80 default_server ipv6only=off;
listen [::]:443 default_server ipv6only=off ssl deferred;These entries are recreated if I disable/enable SSL via the web UI so I assume they don't include any manual hacks that I might have made and forgotten about. My sites work fine alongside the OMV UI with these settings, with everything listening on ports 80/443 but different hostnames set in the server blocks.
On my OMV6 installation I had these entries:
listen *:80 default_server;
listen [::]:80 default_server;
listen *:443 default_server ssl deferred;
listen [::]:443 default_server ssl deferred;My sites aren't served with these settings - the OMV web GUI is served regardless of which hostname is used in the requests. If I change to the v5 settings (removing the ipv4 lines and adding ipv6only=off to the ipv6 lines) everything works as before. As the comment in the file makes clear though, such changes can be overwritten, so presumably this is not a good solution. I created another instance of OMV6 to have a poke around with, and was surprised to see that it has different settings:
listen 80 default_server;
listen 443 default_server ssl deferred;... even though I tried (but presumably failed) to keep both instances the same. Presumably there's something else involved in determining the settings to use. Is there some way I could modify those rules to get OMV6 to use the v5 style settings?
OK, thanks for your efforts.
it's probably something in those maps files that isn't quite right. Do they exist and do they have content?
Sorry, I neglected to answer that bit:
| sender_bcc | myomv@mydomain.com openmediavault-notification@localhost.localdomain |
| sender_canonical | /.+/ myomv@mydomain.com |
| recipient_bcc | [empty] |
| aliases | postmaster: root |
| transport | openmediavault-notification@localhost.localdomain omvnotificationfilter: |
Yes, I thought the distinction between 0.0.0.0 and * might mean that the former was only to any and all network adapters on the local machine with the latter extending to non-local. IPv6 didn't occur to me. As I said, my misunderstanding - thanks for clarifying.
This means, it is listening on all available network addresses, not only localhost. With ths setting, you can not start a docker mail-relay on port 25.
Fair enough, my misunderstanding. Wikipedia says In the context of servers, 0.0.0.0 can mean "all IPv4 addresses on the local machine" (my emphasis) so I thought it might exclude non-local traffic. Other services that are listening across the LAN (e.g. nginx, mysqld) are showing as *:80, *:3306 etc.
Non-standard ports would have to be used for one instance, dockered or otherwise. There may be something lighter, but if I was running it in a docker it wouldn't matter to me one way or the other.
Not if it was on another machine, surely? That's why I suggested putting it elsewhere if I were to go with a separate relay. I agree it would be nicer to have the existing one working as required though, but the main objective is to have things such that they don't require any technical know-how to keep them going.
Another option might be to look at switching to using something like Gmail for sending from my programs. Don't know how complicated the authentication etc. would be (not a problem with the provider I'm currently using).
Postfix listening on localhost only is the default for OMV. But this makes it unreachable from other LAN hosts.
Since the idea is to offer a from the LAN reachable smtpd, having it also listen on the OMV LAN IP is required if you only want to run a single service.
It might explain what I'm seeing though.
# ss -plant | egrep '25|State'
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 100 0.0.0.0:25 0.0.0.0:* users:(("master",pid=30466,fd=13)) Doesn't that mean it's listening to local traffic only?
Would running another SMTP service (even in a Docker) mean that clients need to use non-standard ports instead of 25? That's what made me think about putting it on another machine, Dockered or otherwise (the other machine runs anyway, it wouldn't mean firing up another one). Either way, would Postfix be the ideal choice or is there anything lighter that would listen across the network?
The only differences I noticed when looking at your config are that I had a blank "mydestination =" and I didn't have a "inet_protocols = ipv4" entry. Tried setting them (and restarting postfix) but no change.
compatibility_level = 2
mydomain = mydomain.com
mydestination =
relayhost = relay.myisp.com:25
sender_canonical_maps = regexp:/etc/postfix/sender_canonical
sender_bcc_maps = hash:/etc/postfix/sender_bcc
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
smtp_header_checks = regexp:/etc/postfix/smtp_header_checks
alias_maps = hash:/etc/aliases
transport_maps = hash:/etc/postfix/transport
message_size_limit = 10240000
default_destination_concurrency_limit = 2
default_destination_rate_delay = 1s
smtputf8_enable = no
inet_interfaces = all
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destinationNo change, still working when run on the OMV machine but producing the 'Relay access denied' error when run from another machine on the network.
Taking a step back, I wonder if a better approach might be to install a smtp server on another machine and point OMV at that. I have another 24/7 Debian-based machine that should be suitable. My thinking was that an SMTP daemon on another box could act as an intermediate relay, accepting messages from OMV and any other hosts on my LAN and forwarding them all to my ISP's relay server. Should we change our mail provider I would only have to point my SMTP server at the new provider's server, leaving OMV and various scripts unchanged.
I'm well aware of my lack of experience with such things though, and a quick look around seems to yield mostly setups intended for piping from shell scripts on the local machine, not a service providing for the LAN. I guess I'm out of my depth.