Posts by sebeksd


    My question is related more with Linux and Debian then with OMV, but I hope you will not kick me from here :P

    I saw some time ago then Linux kernel 5.8 has a driver/module for newer Zen base CPUs to monitor energy. I was hoping that after updating kernel to 5.8 on my OMV 5 installation new monitoring device will appear in /sys/class/hwmon, but it didn't :(

    After searching throughout Internet I didn't find anything about manually enabling something, everyone show that after installing new kernel or whole distro new module is in place.

    Anyone know if I need to do/install something, maybe kernel 5.8 is not enough and I need to wait for some additional modules to be added by OMV maintainers?

    I have B550 board with Ryzen 3600 so new energy module should work with it.


    lm_sensors doesn't find new sensors.

    Here is link to article about it:…nergy-Driver-Working-Well


    Now I made simple script to not forget these in future

    monit restart omv-engined
    omv-salt stage run prepare
    omv-salt stage run deploy

    Something is wrong with "OMV_CLAMAV_CLAMD_MAXDIRECTORYRECURSION", after setting it up in "/etc/default/openmediavault" and running "sudo omv-salt stage run prepare" it still shows old value in "/etc/clamav/clamd.conf".


    My clamav scans give me some warnings for example "MaxDirectoryRecursion" so I tried to change that through "extra options" configuration but it was not working.

    Checking "/etc/clamav/clamd.conf" I saw that extra options are on bottom of the file and defaults are on top, moving "extra options" to the top of the file make it working.

    So I check it further and found in source code and it seems that defaults are taken from Open Media Vault variables. Now I'm a little bit confused, what is correct way to configure ClamAV, extra options seems to be correct way from user point of view (its in GUI, variables are not). Maybe variables in this case are legacy way?

    If "extra options" have priority then moving them to the top of clamd.conf should solve that issue (it seems clam is reading only first appearance of the parameter).

    I made few small test:


    GUI Domain = local,

    /etc/resolv.conf = local

    sudo omv-salt stage run prepare - time 11s


    GUI Domain = home,

    /etc/resolv.conf = local

    sudo omv-salt stage run prepare - time 130s


    GUI Domain = local,

    /etc/resolv.conf = local

    sudo omv-salt stage run prepare - time 11s


    GUI Domain = local,

    /etc/resolv.conf = home

    sudo omv-salt stage run prepare - time 26s


    GUI Domain = local,

    /etc/resolv.conf = local

    sudo omv-salt stage run prepare - time 11s


    GUI Domain = home,

    /etc/resolv.conf = home

    sudo omv-salt stage run prepare - time 253s

    Not sure if "/etc/resolv.conf" should change automatically after changing domain in GUI but at least on my server it stays unchanged.

    I have no idea why it is behaving this way but I'm not an "admin" :P

    First of all there was additional "problem" that I didn't mention (because it wasn't big of a deal), not only apply was slower but also web ui loading was "lagging", for example login page was loading for about 3 seconds, then after logging first page load for additional 3 seconds (other pages to, even "widgets" on dashboard was lagging). When I think about it samba shares also was lagging (first open). But 3 seconds is not very long so I was ignoring it. After fixing the problem all mentioned above start to working blazing fast (less then 1 sec ?)/.

    It's look like the problem is related to domain name/domain mismatch, I'm not sure what domain name I set during installation (probably "home") but I know that after some time I changed it in GUI (probably from this moment everything slowed down).

    After debugging salt-call I looked into /etc/resolve.conf to fix:

    [DEBUG ] /etc/resolv.conf: The domain and search keywords are mutually exclusive.

    And then I saw that in this file I had "home" domain (now I don't remember what I had in GUI). One thing Im sure is that on my router I have domain name "local" so I start changing it everywhere, first in GUI then in "resolv.conf" (GUI change did not overwrite this file so I changed it manually).

    Now after setting GUI domain an in resolv.conf everything work very fast, Apply take about 11s (from 250s), GUI is loading instantly and I think samba shares also sped up.

    Now strangest in all of that is that I was always using local IP (no names, always so not sure why it was trying to resolve any think. I was opening GUI with HTTP (no SSL) also using IP.

    I have local DNS on PiHole (in docker on this exact server), my router point this DNS through DHCP.

    Could you please add the following line to /etc/salt/minion.d/openmediavault-test.conf and re-run your test. Is it faster now?

    enable_fqdns_grains: False

    Maybe your issue is related to

    votdev Do you still want me to check that ?

    Few fresh info. I did some source code search for omv-salt and found some "salt-call" command call. This command seems to have debug option (found in Salt Stack documentation).

    So I executed this (I hope I didn't damage anything :P):

    salt-call -l debug --local --retcode-passthrough state.orchestrate omv.stage.prepare

    Loking at the output I saw two major "stops" (they are repeated few times):

    [DEBUG ] Elapsed time getting FQDNs: 40.413857221603394 seconds

    [DEBUG ] LazyLoaded zfs.is_supported

    It is stoping on both of them for quite a while (multiply times).

    There is also (every time before those two lines):

    [DEBUG ] /etc/resolv.conf: The domain and search keywords are mutually exclusive.

    Not sure why its trying to get FQDNs. I will probably try to search more tomorrow.

    Full log in attachment.


    • salt.txt

      (55.34 kB, downloaded 16 times, last: )

    ok. How about:

    sudo /usr/bin/salt-call --local saltutil.clear_cache

    sudo omv-salt stage run prepare

    Same thing. First command took over a minute (not sure how long exactly).

    Second one took similar time like always but result was slightly different

    - modules.omv_conf
    - modules.omv_utils

    Full output:

    Not particularly. It is in verbose mode when you don't use the quiet flag. I would disable monitoring (can enable later if you want it) in the web interface to start. And what is the output of: grep OMV_SHAREDFOLDERS_DIR_ENABLED /etc/default/openmediavault


    And what is the output of: grep OMV_SHAREDFOLDERS_DIR_ENABLED /etc/default/openmediavault


    During "omv-salt..." there is nothing disturbing in logs.

    Only two things I see in logs that look bad are (today):

    Sep 15 07:46:23 SERVER collectd[20823]: plugin_read_thread: read-function of the `df' plugin took 10.240 seconds, which is above its read interval (10.000 seconds). You might want to adjust the `Interval' or `ReadThreads' settings.

    Sep 15 18:13:52 SERVER smbd[28643]: process_usershare_file: stat of /var/lib/samba/usershares/git_repositories failed. Nie ma takiego pliku ani katalogu

    "Nie ma takiego pliku ani katalogu" - mean "no file or directory"

    Is there a way to make "omv-salt" more verbose so I could see what is it doing for so long ?


    Before I installed OMV5 on target hardware I was doing some testing on VM (Virtualbox on Win10). Through all my test all "Apply" commands ware fairly quick (few seconds) and I configured most of things (including some drives) that I wanted on my target machine (which was still in parts at the time).

    After I assembled my new server I installed OMV5 and start configuring it bit by bit. Save/Apply times ware even better than on VM. I did configured most things including Drives/Filesystem (Snapraid + MergerFS), copied 4TB of data and so on. What I remember at this point it was still quite quick. Then for some unknown reason it started to slow down. I think first I've noticed it it was when I tried to install NUT plugin (and have many problems with it, now it's removed). Recently I did run "omv-salt stage run prepare" and I saw that It is reapplying config for over 253 seconds (logs at the bottom).

    Is there a way to easy debug what is going on? My server hardware config is Ryzen 3600@ 3Ghz, RAM 16GB ECC, 128GB Samsung NVMe for system/docker volumes drive, 3x3TB data drives.

    Tested in local network over 1gbps. No SWAP partition.

    "omv-salt stage run prepare" output

    In this guide you show how to import it one time, every time cert renewal proces starts Imported cert become obsolete (or maybe I'm wrong ?) :(

    I would like to see something like in pyMedusa (or Sickrage/SickChill).

    Normally I use Traefik for all my containers so there is no http access to them, but for OMV WEB UI I don't want to use it because if something goes wrong with Trafik I will lose access to server (through WEB).

    I have few other things I need to configure first (transferring from broken QNAP to self build NAS with OMV) so I don't have much time to fiddle with it right now.


    I could not find solution for this, both on forum and on my own, so here is what I want to do.

    I have LetsEncrypt running in docker (I configured it way back on QNAP, now I'm moving to OMV and I still want to use It as a docker container) providing certs for other docker containers and I want to use this certs also on OMV web ui. Problem is I don't want to update certs every time certs are renewed.

    So I just want simple solution, point web ui SSL (nginx ?) to use certs from provided path. Problem is:

    - there is no option in GUI to do that (only certs from "repo" are allowed),

    - there is no way to "import" certs to certs "repo" as path to file (so they automatically pulled every time they got renewed),

    - there is no way to change configs manually because they are overwritten from GUI

    I tried to generate certs from GUI and then remove cert files and replace them with symlinks but It seems it doesn't work.

    Is there any solution to this ? If currently it is impossible how big of a chance is there that someone will add that feature to SSL configuration in GUI (simple path to files instead of cert repo).