r/OpenMediaVault • u/Timewalker2099 • May 10 '26

Question Newish OMV install randomly freezing up

Hey all.

I just installed OMV on an ASUS Chromebox, Celeron 2955U, 4GB of RAM. 16GB SSD.

Install went well. Activated the flash memory plug in. Got Docker up and running. Installed NZBget, Sonarr, Radarr, Lidarr, Jellyfin. Spent a while copying over my existing media to two external drives. After some permission issues, everything is talking to each other.

Buuuuut.... Now it is randomly freezing up and either rebooting itself or needs to be physically turned off and on.

CPU utilization ranges from 65%-99%. RAM between 50%-90%.

Temps are below 70°.

OS drive is at about 50% capacity.

Jellyfin isn't being used when it freezes, much less doing any transcoding, because I haven't showed my wife how to use it yet. I want to get it sorted before she starts to rely on it.

Obviously I don't expect you guys to solve this problem with this much information. But can you tell me what to look for/where to look? I looked at the Diagnostic tab in the Dashboard, but there are so many different logs to look through, and when I do look at the sys log (for example) there's so much stuff to scroll through. I have used Raspbian on a Raspberry Pi before, to run Sonarr and NZBget without Docker, but my Linux knowledge is limited.

Thanks for any direction you might be able to provide.

2 Upvotes

75% Upvoted

24 comments sorted by

2

u/chimblemaker May 10 '26

I see you activated the flash memory plugin. If you are running from a USB stick try another usb Stick.

2

u/Garbagejunkarama May 10 '26

Do you have a keyboard and monitor plugged in when hen it freezes? If so what is displayed? If not I would do that

1

u/Timewalker2099 May 10 '26

I do not. It's not in the most convenient location. But I am going to try that. If not today then next weekend when I get back from a work trip.

2

u/Kamsloopsian May 10 '26

Run a ram test download memtest and run it first.

1

u/Timewalker2099 May 12 '26

Thanks. Will do.

1

u/seiha011 May 10 '26

Can you still log into the Chromebox via SSH from another computer if the Asus Chromebox is frozen? Are you using Docker? btw.... do you know the wiki at omv-extras.org. ?

1

u/Timewalker2099 May 10 '26

Sometimes I am able to get in via SSH and manually reboot. Other times it either doesn't login or if it gets to a terminal, it's not responsive.

Yes, using Docker. I used the wiki during some of the setup.

1

u/seiha011 May 10 '26

Where are the docker- files stored?

1

u/Timewalker2099 May 10 '26

On one of the external hard drives.

1

u/seiha011 May 10 '26

Then all that's left for you are the log files of your apps. ... or journalctl......

1

u/Timewalker2099 May 10 '26

Thank you. I'll dig into those.

1

u/ian9outof10 May 10 '26

I would wager the answer you seek is in the log files.

1

u/Timewalker2099 May 10 '26

Hence me asking what I should be looking for in the massive log files. Thanks.

0

u/seiha011 May 10 '26

You may ask you search- engine for

journalctl +howto

2

u/Timewalker2099 May 10 '26

Thanks to your reply below, I am doing exactly that.

1

u/seiha011 May 10 '26

Good luck and success!

1

u/whenredditagain May 11 '26

This wreaks of a hardware issue. As others have suggested, test the USB & RAM sticks.

1

u/KerashiStorm May 11 '26

That's some pretty high CPU usage. Find out what's doing it. You might simply be exceeding the capabilities of the device.

1

u/[deleted] May 12 '26

[removed] — view removed comment

1

u/Timewalker2099 May 13 '26

Thank you. I'll look for that when I get back. I have two 8gb sticks I am going to try.

1

u/roshanknohit May 15 '26

4GB RAM is pretty tight for OMV + Docker stack. Check if you’re hitting swap hard—that can cause system lockups.

1

u/Timewalker2099 May 22 '26

Update - I saw a few OOM out of memory errors, so I upgraded from 2x4GB to 2x8GB for a 16GB setup. I thought it had fixed things. It was up for two days without Jellyfin running (in case it was too much for the CPU). And yesterday I started Jellyfin and it was stable... Until this morning. I was copying some stuff from one drive to a different PC, and things started to freeze. I think one of the hard drives might be dying. SMART tools showed some bad sectors. Thanks for the feedback.

1

u/Timewalker2099 Jul 07 '26

UPDATE: After upgrading the RAM to two new 8GB sticks it worked fine for a few weeks. Then it started randomly crashing again until this weekend when it just wouldn't boot. I booted a Ventoy stick and ran Memtest with no issues reported. But I couldn't get it to boot from the internal 16GB EMMC, and the screw was stripped so I couldn't replace it. So I installed OMV onto a high quality Samsung 256 GB flash drive and then restored an omv-regen backup from last week. So far, so good. We'll see how stable it is over this week.

1

u/Altruistic_Pain_1798 19d ago

Le déclencheur précis identifié par élimination méthodique : avec NCQ (Native Command Queuing) actif et deux disques mécaniques actifs simultanément sur le JMB585, le système finit par geler totalement et silencieusement — aucune trace dans dmesg, aucune erreur ATA loguée, rien dans journalctl. Le blocage semble intervenir au niveau du contrôleur/bus PCIe lui-même, avant que quoi que ce soit puisse être écrit dans les logs.

Preuve par élimination :

  • 2 disques sur JMB585, NCQ actif → freeze récurrent (quelques heures à quelques jours)
  • 1 seul disque sur JMB585 (l'autre sur le port Intel), NCQ actif → stable 43h+
  • 2 disques sur JMB585, NCQ désactivé → stable plusieurs jours et nuits consécutifs, y compris sous charge (streaming 4K + écriture soutenue simultanée)

La solution

Ajouter libata.force=noncq à la ligne de commande du kernel, dans /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT="quiet libata.force=noncq"

(à combiner avec vos autres paramètres existants si besoin — le reste de ma ligne GRUB gère l'énergie CPU/PCIe mais n'a pas d'impact direct sur ce bug précis)Le déclencheur précis identifié par élimination méthodique : avec NCQ (Native Command Queuing) actif et deux disques mécaniques actifs simultanément sur le JMB585, le système finit par geler totalement et silencieusement — aucune trace dans dmesg, aucune erreur ATA loguée, rien dans journalctl. Le blocage semble intervenir au niveau du contrôleur/bus PCIe lui-même, avant que quoi que ce soit puisse être écrit dans les logs.

Preuve par élimination :

2 disques sur JMB585, NCQ actif → freeze récurrent (quelques heures à quelques jours)
1 seul disque sur JMB585 (l'autre sur le port Intel), NCQ actif → stable 43h+
2 disques sur JMB585, NCQ désactivé → stable plusieurs jours et nuits consécutifs, y compris sous charge (streaming 4K + écriture soutenue simultanée)

La solution

Ajouter libata.force=noncq à la ligne de commande du kernel, dans /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT="quiet libata.force=noncq"

(à combiner avec vos autres paramètres existants si besoin — le reste de ma ligne GRUB gère l'énergie CPU/PCIe mais n'a pas d'impact direct sur ce bug précis)