This is all kinds of awesome. Thank you for being the one to come up with this. 🙂
Question: will this app show the yellow 'apply changes' banner (if there is one) after updates are installed, and allow for the user to do so?
This is all kinds of awesome. Thank you for being the one to come up with this. 🙂
Question: will this app show the yellow 'apply changes' banner (if there is one) after updates are installed, and allow for the user to do so?
It may be possible to start a RAID 5 array from an existing single disk by adding two more, but assuming that it even is, it would take some serious command-level trickery. Not worth the trouble and risk to your data.
Wipe your 3 good disks, create the RAID, format it to ext4 (or another Linux filesystem of your choice), then copy your backup to the array. After that, you can re-create shared folders and the like.
You'll want to wipe your disks first (a quick wipe is sufficient). Go to Storage -> Disks to do so.
This tells OMV that they're ready to be used - either formatted individually, or added to a new RAID array as in your case.
Ich spreche Deutsch und verstehe Dein Dilemma.
You're on the right track - something went wrong backing up data from one server to the other, so now you have a folder in /root/ that's actually named [Steven@]192.168.1.124::NAS Backup - and that's almost certainly what's taking up all your disk space.
It looks like a syntax error to me. Can you post the full command or script you use for your backup? (Please quote it in a code box.)
I think the Asus and Gigabyte ITX mobos will both serve you well (personally, I would prefer the Asus).
Since you won't be using a graphics card, you can easily get more SATA ports via a PCIE expansion card, if needed, and still use the M.2 slot for the OS drive.
In practical terms, the only true difference between the i3 and i5 CPUs is the core/thread count. I'd say stick with the i3 as it's already pretty powerful - unless the price difference is negligible, or you plan on running one or multiple VMs.
Nice AI response... but it doesn't apply to armbian-config; there literally is no 'stable' release channel for it.
I have no experience with Pi's and couldn't speak to the SMB issue.
(I am wondering, though, why you have mkvtoolnix installed on your system.)
For starters, can you post the compose files for your two containers here?
armbian-config updates very frequently for me as well (it doesn't bother me).
I think there was some announcement or post on the Armbian forums saying that this was by design and there is no "stable" branch to speak of, really.
The version number 6.12.107 refers to the Linux kernel, that's not the OMV version.
So you do have access to the commandline. Run df -h as suggested and post the output here.
I'm not sure what you're asking exactly - do you intend to install OMV on the USB stick on one server, then boot from it on the other server?
If yes, that should work but the commonly given advice is to run omv-firstaid in a commandline session to reset and re-establish network connectivity.
Migrating configurations and databases is relatively easy with Emby for sure - I transitioned from a host-level installation to a Docker container without having to set up a lot of things again. Look into whether your -arrs offer similar backup and restore features.
You could try disabling, then re-enabling monitoring to see if that gets it going again. Be sure to apply pending changes at each step as prompted.
Also, are you using the writecache plugin, and is it the latest version?
If a user runs wget without sudo and didn't reboot - or, in fact, start a fresh terminal session - before doing so, isn't it plausible that another sudo command was already entered in the same terminal session at that point, so that the install script wouldn't be stopped by an invisible password prompt?
The GitHub link above says this:
sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/installOld7 | sudo bash
So, adding a sudo before wget, and referring to a script 'installOld7' instead of just 'install'.
To make the drive visible to USBImager under Windows, you can use Disk Management to assign a drive letter to the partition on your USB drive. Most likely you will then be prompted to format the partition - of course you don't want to do that.
If Disk Management doesn't give you the option to assign a drive letter, then diskpart in an administrative-level commandline window is another way to do this.
And it still could be. rrdcache is very sensitive to any changes. It has been recommended to disable monitoring when using flashmemory/writecache since the beginning. I still add rrdcache's directories because I know people won't follow that advice.
I wasn't even aware of this recommendation. What, exactly, will I lose by turning off monitoring?
I don't have a problem doing so as long as I still get notified of potential issues (like cron job results or SMART errors, for example). With monitoring disabled, would monit still catch non-running services and restart as needed? Just trying to get an idea of what the on/off toggle really entails.
QuoteI didn't say it wasn't writecache. I was just saying it is frustrating that it is blamed for every problem especially when I push out an update. I don't know what else I can do. I have hundreds of automated tests and run it on all of my systems before pushing out updates but obviously I can't replicate every omv setup. I even have AI look for weaknesses in writecache every time a new model comes out. Yet, people still have problems. It gets old...
That makes a lot of sense - I'm sorry to add to the frustration. Know that I definitely wasn't trying to assign any blame - rather, I felt that there might be a bug and I should bring it to someone's (your) attention. It's all good.
QuoteThis might be one of the hardest things to diagnose and to do it through forum posts takes time and patience I don't have.
Absolutely fair.
QuoteI'm not sure how you can get rrdcache emails when it is disabled. Maybe the flush restored the emails?
I wouldn't know. However, since my last post there have been no more emails. They just... stopped. The syslog spam is still happening, though.
I'm going to go ahead and turn off monitoring in the GUI, but please put my mind at ease and let me know what exactly it is I'm turning off. ![]()
EDIT ... oh, I see. It's just the performance statistics that get turned off, right? Works for me - I have no need of them.
Not blaming it at all. I simply thought there might be an issue with it since the monit trouble started after updating the plugin. And you have to admit that when this happens right at flush/rotate time, that seems a bit more than a coincidence (at least to someone with limited knowledge, like yours truly).
You say it's not writecache, and of course I'll take your word for it. Having said that, I was hoping for some advice as to how to stop this syslog spam and the email notifications.
In the meantime, though, I've followed a suggestion to disable monitoring in the OMV GUI, apply the changes, re-enable it, and apply the changes again. That seems to have worked for now... no more syslog spam. If the emails stop as well, I will mark this thread resolved (and even wear a dunce hat).
Update... nope, I got the same two emails again just now.
Addendum - I'm also seeing a TON of this in syslog:
Further addendum - After seeing another thread about a similar issue, I ran omv-salt deploy run monit on both of my systems.
That seemingly didn't do much, except now my main system - the one that's configured to flush/rotate hourly - is now sending me the same monit and rrdcached emails every hour.
🫣
Since the omv-writecache plugin updated from 8.2.2 to 8.2.3 on both my AMD64 and arm64 OMV servers yesterday, monit seems to be unhappy for some reason.
Got two notification emails today (Sep. 6) at 2:39 pm, one saying that the rrdcached service does not exist (prompting monit to restart), the other one saying the restart failed.
First email:
QuoteDisplay MoreThe system monitoring needs your attention.
Host: backserv
Date: Sun, 06 Sep 2026 14:39:34
Service: rrdcached
Event: Does not exist
Description: process is not running
This triggered the monitoring system to: restart
Second email:
QuoteDisplay MoreThe system monitoring needs your attention.
Host: backservDate: Sun, 06 Sep 2026 14:40:04
Service: rrdcached
Event: Execution failed
Description: failed to start (exit status 0) -- no output
This triggered the monitoring system to: alert
My WriteCache settings on backserv (the arm64 system) are as follows. Note that it's set up for daily flush/rotate at ... yep, 2:39 pm.
Output of systemctl --full --no-pager status monit:
(This started around the 14:39 time stamp and just keeps going on)
● monit.service - Pro-active monitoring utility for unix systems
Loaded: loaded (/usr/lib/systemd/system/monit.service; enabled; preset: enabled)
Active: active (running) since Sun 2026-09-06 14:39:04 EDT; 35min ago
Invocation: d7502e8268f640b2840e2bcdefacad5b
Docs: man:monit(1)
https://mmonit.com/wiki/Monit/HowTo
Main PID: 100044 (monit)
Tasks: 2 (limit: 4297)
Memory: 4.6M (peak: 6.1M)
CPU: 4.205s
CGroup: /system.slice/monit.service
└─100044 /usr/bin/monit -I
Sep 06 15:12:41 backserv monit[100044]: 'rrdcached' trying to restart
Sep 06 15:12:41 backserv monit[100044]: 'rrdcached' start: '/bin/systemctl start rrdcached'
Sep 06 15:13:11 backserv monit[100044]: 'rrdcached' failed to start (exit status 0) -- no output
Sep 06 15:13:41 backserv monit[100044]: 'rrdcached' process is not running
Sep 06 15:13:41 backserv monit[100044]: 'rrdcached' trying to restart
Sep 06 15:13:41 backserv monit[100044]: 'rrdcached' start: '/bin/systemctl start rrdcached'
Sep 06 15:14:11 backserv monit[100044]: 'rrdcached' failed to start (exit status 0) -- no output
Sep 06 15:14:41 backserv monit[100044]: 'rrdcached' process is not running
Sep 06 15:14:41 backserv monit[100044]: 'rrdcached' trying to restart
Sep 06 15:14:41 backserv monit[100044]: 'rrdcached' start: '/bin/systemctl start rrdcached'
Display More
Output of systemctl --full --no-pager status rrdcached:
● rrdcached.service - LSB: start or stop rrdcached
Loaded: loaded (/etc/init.d/rrdcached; generated)
Active: active (exited) since Sat 2026-09-05 18:56:00 EDT; 20h ago
Invocation: ffb53509f05647dbbe6716d42232e7f6
Docs: man:systemd-sysv-generator(8)
Process: 2006 ExecStart=/etc/init.d/rrdcached start (code=exited, status=0/SUCCESS)
Mem peak: 61.3M
CPU: 6min 8.242s
Sep 05 18:55:59 backserv systemd[1]: Starting rrdcached.service - LSB: start or stop rrdcached...
Sep 05 18:56:00 backserv rrdcached[2006]: rrdcached started.
Sep 05 18:56:00 backserv systemd[1]: Started rrdcached.service - LSB: start or stop rrdcached.
Display More
This never happened before, and I didn't change any settings in the writecache plugin. Everything else seems to be working just fine, it's just the endless error logs.
It's also interesting to note that this only affects my arm64 server. My main AMD64 system flushes/rotates both hourly and daily at 5:33 am, and has not complained at all.
What's going on, and what's the fix?
It's possible. I have no experience with Raspberry Pi's, but have heard that a stronger power supply for the Pi may help.
Assuming you're using these drives for OMV storage and shared folders, you shouldn't format them as exFAT, though. Stick with ext4 or another Linux native filesystem. EDIT: I just saw you already did that.
What did you use to clone?
And: are you using the original 1TB disk and the 2TB clone at the same time? It will cause problems if you do so, because the two disks have the same UUID and this will confuse your system (specificially, the Linux kernel). There are ways to fix this, though.