The issue is now fixed, and the problem is not related to OMV!
Posts by auanasgheps
-
-
I confirm that APC and Eaton are great with NUT and provide lots of info.
-
For me scrubbing is important for the health of the files.
For me too, and my post wasn't encouraging to disable scrub if you don't know what you are doing.
I use SnapRAID, not regular RAID, which has a flexible and convenient method of doing little partial scrubs every day.
-
Sounds interesting. Care to share some details of what me might expect to see in the update?

It will include a new notification system which is much more reliable and flexible compared to the previous one. And also a couple of minor changes, plus lots of bugfixes and logic/safeguards improvements.
Most of what I'm saying is already on Github, and the installation is super easy.
That's why I haven't focused on the integration with the plugin, but it will happen.
-
Any update regarding adding some of the features from the AiO script by auanasgheps?
Not yet, but it's still my next objective. I first have to release the next major update.
-
Yes, this is a common problem when mounting Borg backups with FUSE, which by default limits the access to the mount user.
When executing the command, if done via the CLI, you can add the allow_other option.
Otherwise you can adjust FUSE configuration (/etc/fuse.conf) and add the option there.
And yes, it will be available via SMB!
-
I've tested the latest test package which contains the newly added services and it works perfectly. Thank you!
-
Postfix wasn't fully working yet with the test version.
You have to add a specific service to the systemd file.I fixed the issue by adding a new line
More info here.
I have solved both Postfix and nginx doesn't exist/exist emails, while sending a test email to verify Postfix is alive.
-
Thanks again to wenzhuo for the help. You are a master!
I have tested it and this this fixes two issues:
- Postfix getting stuck (worked around with a scheduled service reboot after system boot)
- Email about nginx does not exist/exists (which I could not workaround)
Edit the folder2ram_startup.service systemd: systemctl edit folder2ram_startup.service --full
Add the following to
the [Unit] sectionCodeRequiresMountsFor=/var Wants=tmp.mount Before=monit.service rrdcached.service minidlna.service nginx.service nmbd.serviceIt should look like this
Code[Unit] Description=folder2ram systemd service After=local-fs.target After=blk-availability.service DefaultDependencies=no RequiresMountsFor=/var Wants=tmp.mount Before=monit.service rrdcached.service minidlna.service nginx.service nmbd.serviceSave and reboot.
ENJOY!
-
Sorry, my bad.
I've checked the documentation and I made a mistake in the environment variable: it'sOMV_BTRFS_SCRUB_ENABLED
-
Hi,
Yesterday I received a scrub report notification for each of my disks:
CodeScrub report of the file system mounted at /srv/dev-disk-by-uuid-7e5bf71c-c945-4bea-8f96-6ebe8545198d [UUID=7e5bf71c-c945-4bea-8f96-6ebe8545198d] Scrub device /dev/sda (id 1) done Scrub started: Sat Jun 14 11:46:18 2025 Status: finished Duration: 5:44:44 Total to scrub: 4.73TiB Rate: 239.40MiB/s Error summary: no errors foundI've previously set the variable OMV_BTRFS_SCRUB_ENABLE to NO, but it still ran.
What should I do to disable it?
I am using SnapRAID which has built-in scrub feature, that's why I don't want another one.
Thanks!
-
did anyone find a fix for this? I run two OMV7 servers on similar but slightly different hardware. One of my servers send email notifications fine, the other one hangs and does not send notifications until I run `sudo systemctl restart postfix` and then I get a flood of emails.
The only thing that is really different (and how I started noticing it) was I run this snapraid script https://github.com/auanasgheps/snapraid-aio-script by auanasgheps but I am not sure if that is the cause of the issue.
any help is appreciated, happy to provide further information.
My script only uses the current OMV Postfix configuration, so it doesn't make any changes regarding email.
I am seeing the same issue with postfix (emails not being sent) , because I'm running the flashmemory plugin. If you are too, unfortunately this is to be expected with OMV7 (don't know why, OMV6 worked flawylessly with this plugin).
More info can be found here.
The workaround for me is to set a cron job on restart to 60 seconds:
To be honest I'm evaluating the replacement of my USB thumb drive with a USB SSD so I can discard the plugin.
-
By the way, you are not using the stable
Bookworm 6.1.x kernel! You are using the
coming up 6.12.x backport kernel (Trixie)!
I haven't done anything related to the kernel. I just regularly update the system by running omv-upgrade, so it got installed automatically!
-
Hi, I am hijacking this thread just to make ryecoaaron aware that I've found another issue related to the flashmemoryplugin:
It's just an alert, the service doesn't get stuck like postfix, but I wanted to make you aware.
-
I can confirm that by uninstalling the flashmemory plugin the email alert goes away. I've rebooted the system twice.
I already have the latest stable kernel: Linux 6.12.22+bpo-amd64
-
I meant the docker storage field on the Settings tab in the Compose plugin. If you leave it blank, the plugin won't change daemon,json. Then you can just manually edit daemon.json instead of trying to add saltstack code.
Allright, I can go with this approach!
The salt code itself is working, but I'm sure I'm doing something wrong since the Compose plugin isn't applying it (albeit no errors are displaied right now)
-
Unless you leave the docker storage blank. Then the plugin/salt doesn't touch the daemon.json file.
If your code posted is the code you are using, the formatting is causing the problem.
And yes, the docker storage has been added to the Compose config, since I'm using a NVMe for Docker but the system is run from a slow thumb drive.
The code I posted is exactly the one I'm using, with the exception of real paths to cert files.
I've tested it locally and it works if I execute
So what formatting should I check?
EDIT: woops, the copy paste didn't work correctly, let me fix that. The code is now updated with the actual one I'm using. -
Hi,
I'd like to add TLS config to the Docker daemon, because I have a Docker container that uses such API to get some data.
The Compose plugin doesn't have this option and it overrides any configuration to /etc/docker/daemon.json as expected.
I'm aware it's an advanced config so I'm not asking to expose it in the GUI.
I'm trying to add it via a Salt config, but I'm doing something wrong.
I created the file /srv/salt/omv/deploy/compose/60docker-tls.sls
With this content:
Code
Display More# Add Docker TLS config configure_docker_tls: file.serialize: - name: /etc/docker/daemon.json - formatter: json - merge_if_exists: True - dataset: tls: true tlsverify: true tlscacert: /path/to/ca.pem tlscert: /path/to/daemon-cert.pem tlskey: /path/to/daemon-key.pem hosts: - "unix:///var/run/docker.sock" - "tcp://0.0.0.0:2376"The file is picked up by the compose plugin during the save process, because earlier on I was using a wrong syntax and was throwing an error.
Now it doesn't error out but it simply doesn't apply the configuration.
Can you help on this? -
Hi,
Few weeks ago I've done a fresh install of OMV 7 on my main system. Since then I am receiving nginx alerts at every start up.
They are two and are always delivered together:
Code
Display MoreMonitoring restart -- Does not exist nginx The system monitoring needs your attention. Host: nas Date: Tue, 03 Jun 2025 11:01:10 Service: nginx Event: Does not exist Description: process is not running This triggered the monitoring system to: restartCode
Display MoreMonitoring alert -- Exists nginx The system monitoring needs your attention. Host: nas Date: Tue, 03 Jun 2025 11:02:10 Service: nginx Event: Exists Description: process is running with pid 12356 This triggered the monitoring system to: alertSo it seems that it recovers, but I'd like to fix the issue.
This issue is very similar to this thread, but it's not the same.
I am running the flashmemory plugin which is causing issues to postfix (apparently fixed with a delayed restart of the service)
OMV version is: 7.7.7-1
Here's my systemd-analyze blame output:
Code
Display More40.028s postfix.service 21.510s openmediavault-issue.service 14.385s docker.service 14.278s folder2ram_startup.service 5.165s systemd-networkd-wait-online.service 4.403s containerd.service 4.051s srv-dev\x2ddisk\x2dby\x2duuid\x2db80b861a\x2d7de2\x2d4733\x2da1c8\x2d07> 3.454s srv-dev\x2ddisk\x2dby\x2duuid\x2d7e5bf71c\x2dc945\x2d4bea\x2d8f96\x2d6e> 3.369s smbd.service 2.546s php8.2-fpm.service 2.261s samba-ad-dc.service 2.194s dev-sdd2.device 2.143s openmediavault-engined.service 1.489s systemd-journal-flush.service 1.481s phpsessionclean.service 1.368s smartmontools.service 1.137s systemd-udevd.service 1.049s rrdcached.service 760ms smartctl-hdparm.service 741ms avahi-daemon.service 705ms dbus.service 682ms systemd-logind.service 667ms chrony.service lines 1-23...skipping... 40.028s postfix.service 21.510s openmediavault-issue.service 14.385s docker.service 14.278s folder2ram_startup.service 5.165s systemd-networkd-wait-online.service 4.403s containerd.service 4.051s srv-dev\x2ddisk\x2dby\x2duuid\x2db80b861a\x2d7de2\x2d4733\x2da1c8\x2d07cd3d836474.mount 3.454s srv-dev\x2ddisk\x2dby\x2duuid\x2d7e5bf71c\x2dc945\x2d4bea\x2d8f96\x2d6ebe8545198d.mount 3.369s smbd.service 2.546s php8.2-fpm.service 2.261s samba-ad-dc.service 2.194s dev-sdd2.device 2.143s openmediavault-engined.service 1.489s systemd-journal-flush.service 1.481s phpsessionclean.service 1.368s smartmontools.service 1.137s systemd-udevd.service 1.049s rrdcached.service 760ms smartctl-hdparm.service 741ms avahi-daemon.service 705ms dbus.service 682ms systemd-logind.service 667ms chrony.service 653ms collectd.service 620ms monit.service 618ms rsyslog.service 503ms networking.service 476ms openmediavault-beep-up.service 451ms lvm2-monitor.service 446ms systemd-networkd.service 430ms run-rpc_pipefs.mount 402ms loadcpufreq.service 395ms ssh.service 285ms wpa_supplicant.service 261ms e2scrub_reap.service 257ms postfix@-.service 252ms docker.socket 225ms lm-sensors.service 166ms systemd-tmpfiles-setup-dev.service 166ms systemd-resolved.service 145ms modprobe@drm.service 143ms cpufrequtils.service 127ms systemd-udev-trigger.service 125ms systemd-sysusers.service 117ms systemd-journald.service 104ms modprobe@dm_mod.service 102ms systemd-sysctl.service 88ms systemd-random-seed.service 75ms openmediavault-firewall.service 72ms systemd-remount-fs.service 71ms modprobe@efi_pstore.service 67ms srv-dev\x2ddisk\x2dby\x2duuid\x2d0121a485\x2d4bdc\x2d4f1f\x2d8d3e\x2d8b8a42c49508.mount 62ms systemd-tmpfiles-setup.service 60ms modprobe@loop.service 60ms dev-hugepages.mount 57ms dev-mqueue.mount 54ms sys-kernel-debug.mount 53ms systemd-modules-load.service 51ms sys-kernel-tracing.mount 51ms rpc-statd-notify.service 47ms kmod-static-nodes.service 46ms rpcbind.service 44ms modprobe@configfs.service 42ms modprobe@fuse.service 39ms ifupdown-pre.service 35ms systemd-network-generator.service 32ms boot-efi.mount 29ms systemd-fsck@dev-disk-by\x2duuid-0121a485\x2d4bdc\x2d4f1f\x2d8d3e\x2d8b8a42c49508.service 28ms openmediavault-cleanup-php.service 28ms systemd-binfmt.service 28ms systemd-fsck@dev-disk-by\x2duuid-7e5bf71c\x2dc945\x2d4bea\x2d8f96\x2d6ebe8545198d.service 25ms openmediavault-cleanup-monit.service 24ms systemd-update-utmp.service 21ms srv-dev\x2ddisk\x2dby\x2duuid\x2d0121a485\x2d4bdc\x2d4f1f\x2d8d3e\x2d8b8a42c49508-swapfile.swap 17ms systemd-update-utmp-runlevel.service 16ms systemd-fsck@dev-disk-by\x2duuid-b80b861a\x2d7de2\x2d4733\x2da1c8\x2d07cd3d836474.service 13ms nginx.service 12ms sys-fs-fuse-connections.mount 11ms proc-sys-fs-binfmt_misc.mount 10ms systemd-user-sessions.service 8ms sys-kernel-config.mount 3ms tmp.mount 77us blk-availability.service 54us folder2ram_shutdown.service -
Sorry for the spam, but the solution unfortunately is not reliable, I can't get postfix to work reliably.
I've done another reboot and it's stuck:Code
Display Moreroot@nas:~# journalctl -f May 29 18:41:02 nas postfix/smtpd[13978]: warning: connect #1 to subsystem private/proxymap: Connection refused May 29 18:41:12 nas postfix/smtpd[13978]: warning: connect #2 to subsystem private/proxymap: Connection refused May 29 18:41:22 nas postfix/smtpd[13978]: warning: connect #3 to subsystem private/proxymap: Connection refused May 29 18:41:32 nas postfix/smtpd[13978]: warning: connect #4 to subsystem private/proxymap: Connection refused May 29 18:41:42 nas postfix/smtpd[13978]: warning: connect #5 to subsystem private/proxymap: Connection refused May 29 18:41:52 nas monit[795]: Mail: Error receiving data from the mailserver -- Resource temporarily unavailable May 29 18:41:52 nas monit[795]: Alert handler failed, retry scheduled for next cycle May 29 18:41:52 nas postfix/smtpd[13978]: warning: connect #6 to subsystem private/proxymap: Connection refused May 29 18:42:02 nas postfix/smtpd[13978]: warning: connect #7 to subsystem private/proxymap: Connection refused May 29 18:42:12 nas postfix/smtpd[13978]: warning: connect #8 to subsystem private/proxymap: Connection refused May 29 18:42:22 nas postfix/smtpd[13978]: warning: connect #9 to subsystem private/proxymap: Connection refused May 29 18:42:32 nas postfix/smtpd[13978]: warning: connect #10 to subsystem private/proxymap: Connection refused