Providing help and getting ETA for OMV8

  • Hi,


    Reading the forum and git, I can see a lot of work preparing OMV8. :thumbup:


    Do you think you're close to the release, or there is still a lot to do?

    (approximate ETA, or % milestone ?) ((Sorry for being that guy asking for an ETA, you'll get why if you read context! 8o ))


    And if there's still a lot to do, is there anything that would need testing that I could help with?


    For context:

    I'm up to reinstall my NAS after updating backup (I mainly wanna try Btrfs instead of Ext4 and also my system drive needs replacement).
    So it's a good time to run tests, and to then clean install OMV8 when ready.

    Though I would appreciate an approximate ETA (~weeks or ~months) in order to organize some of my workflows without a NAS in the meantime.


    All the best!


    PS: Just to cheer you up, I wanna mention I've checked the NAS distro options as I was up to reinstall... No doubt, OMV is still the greatest! <3
    I'd be happy to help if I can.

    • Official Post

    It would be great if someone have a look at all plugins, e.g. if they can be installed and running. Additionally all settings that can be configured via UI. I can not test everything on my own, so it would be great to have support from the community here.


    The planned ETA is before Christmas.

  • Do you prefer all my reports here, or one topic per report?


    First of all: Every core feature tested so far works as expected


    1. After a fresh install, no more DNS response. It is to be noted that I'm on DHCP with fixed ipv4 (set with MAC) and dynamic IPv6.

    First login to admin interface failed after a long delay, then second one worked.


    dmesg shows loads of the following:

    [ 303.592157] systemd-sysv-generator[18203]: SysV service '/etc/init.d/rrdcached' lacks a native systemd unit file, automatically generating a unit file for compatibility.

    [ 303.592162] systemd-sysv-generator[18203]: Please update package to include a native systemd unit file.

    [ 303.592164] systemd-sysv-generator[18203]: ! This compatibility logic is deprecated, expect removal soon. !


    A reboot fixed DNS response.


    2. Network config

    After first reboot, though it shows IPv6 as "disabled", my system still has a local and public IPv6 assigned (visible with "ip a" command).


    3. MD RAID

    It is a plugin now? Already was like that in OMV7? It's been a while since my last install.

    Are you encouraging leaving MDADM for direct RAIDs with Btrfs, or maybe just providing more flexibility/cleaning for those who don't need it? Other reason that I can't think of?


    4. User management

    There are 3 empty "tags" on my default user created during Debian install. Small detail but always nice if fixable.

    Also login to my default user didn't work with password set at OS level, so I would assume it cannot use PAM if no password has been set within OMV? If expected, alright, if not, PAM must be checked.


    5. Updates management

    Seems like ticking "Pre-release updates" adds packages (such as Kernel 6.17.8). But unticking it doesn't remove them. The disable logic likely needs to be checked.



    Side note, while I'm there:

    Notifications such as:

    "Applied the configuration changes.

    3 minutes ago"

    -> Not very useful unless you specify what's been changed, either within the "3 dots" menu, on hover, or under text description. Under text may show "x changes" (amount of changes), and menu "Show changes". Then log everything. Otherwise it's just pure visual pollution.

    Also the "Copy to clipboard" feature is greyed out on these, while others such as these can be copied:

    "Updated SMB/CIFS settings.

    19 minutes ago"

    It is inconsistent.


    I hope this is somewhat useful insight since that's my first time actively looking for issues in OMV.

    I'll dig a bit more tomorrow if I can (unsure, big day), otherwise during the weekend.

    Cheers!

    • Official Post

    1. This is something the OMV project can't fix.OMV is consuming this Debian packaged software, but does not maintain it.

    2. OMV displays the configuration, NOT the real status in the Network datatable and pages. Use the Details action button to display live data.

    3. MD management has been relocated into a plugin. Not everyone needs it. The user can decide between MD or BTRFS or whatever RAID solution.

    4. Plesae post the output of getent passwd. There must be some weird thing in the gecos field.

    5. That's how it works. Your Debian or Ubuntu system also does not uninstall packages if you unconfigure a package repository.

    • Official Post

    Seems like ticking "Pre-release updates" adds packages (such as Kernel 6.17.8). But unticking it doesn't remove them. The disable logic likely needs to be checked.

    pre-release updates does not add the backports kernel (6.17). It just happened to update your apt cache. OMV enables backports by default. You can disable it from the command line or in omv-extras.

    omv 8.0.6-2 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.2 | compose 8.1.2 | cterm 8.0 | borgbackup 8.0.2 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • 1. This is something the OMV project can't fix.OMV is consuming this Debian packaged software, but does not maintain it.

    2. OMV displays the configuration, NOT the real status in the Network datatable and pages. Use the Details action button to display live data.

    3. MD management has been relocated into a plugin. Not everyone needs it. The user can decide between MD or BTRFS or whatever RAID solution.

    4. Plesae post the output of getent passwd. There must be some weird thing in the gecos field.

    5. That's how it works. Your Debian or Ubuntu system also does not uninstall packages if you unconfigure a package repository.

    Thanks!


    1. Well, DNS resolution stopped after installing OMV, not after installing Debian itself, which worked fine on its own. Do you mean the root cause for this issue comes from Debian rather than OMV?

    2. Well, if OMV shows different data than what is set by the system, can we agree that this is a problem? There could maybe be a mechanics to display the user that it's unsynced yet because managed at OS level.

    3. Perfect OK!

    4. Yep, unvisible tags correspond to these comas, i guess, so that would be a Debian installer issue. Maybe OMV could be adapted to not show empty flags... or just keep it like that so that we know there are there:

    lrob:x:1000:100:lrob,,,:/home/lrob:/bin/bash


    pre-release updates does not add the backports kernel (6.17). It just happened to update your apt cache. OMV enables backports by default. You can disable it from the command line or in omv-extras.


    5. Well if it enables backports by default, it shouldn't be unticked by default within the inteface. After checking, file "

    openmediavault-kernel-backports.list" appears to have been added upon OMV installation, according to its date of modification.Again, like 2., thats an inconsistency between what OMV shows versus what's actually set at OS level, which is confusing for users. OMV should either read the actual config file before determining the status, or tick it by default since it enables it by default upon install. Also, seems like it didn't run apt-update && apt-upgrade after enabling backports... But which is expected if DNS resolution was broken (point 1.), so fixing 1. and making sure it runs update/upgrade would be great.

    Edited once, last by UltimateByte: show actual username that wasn't even properly hidden lol ().

    • Official Post

    Well if it enables backports by default, it shouldn't be unticked by default within the inteface

    pre-release is NOT backports. pre-release is a repo in the omv repos. backports is a debian repo. There is no checkbox in the omv web interface to enable/disable backports. That is why I added buttons in omv-extras. OMV has had this behavior for over a decade.

    gain, like 2., thats an inconsistency between what OMV shows versus what's actually set at OS level, which is confusing for users. OMV should either read the actual config file before determining the status

    That isn't how configuration management works. The source of truth is not the config files. It is the database. saltstack just makes the config files match the database. If your config files don't match, then it is likely that you or another service changed them. Like the network table issue, it is showing what is in the database.

    omv 8.0.6-2 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.2 | compose 8.1.2 | cterm 8.0 | borgbackup 8.0.2 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Official Post

    2. Well, if OMV shows different data than what is set by the system, can we agree that this is a problem? There could maybe be a mechanics to display the user that it's unsynced yet because managed at OS level.

    This is only a problem insofar as it indicates that someone else has modified the configuration files. OMV is the master of the system, and the database is the source of truth. OMV only works in this direction; it does not synchronize configuration settings back to the database. Anyone looking for that functionality must resort to other products, such as Webmin.

    • Official Post

    1. Well, DNS resolution stopped after installing OMV, not after installing Debian itself, which worked fine on its own. Do you mean the root cause for this issue comes from Debian rather than OMV?

    This is documented here: https://docs.openmediavault.or…stallation/on_debian.html


    I was referring to the rrdcached syslog output rather than the DNS issue.

    • Official Post

    Fixed with https://github.com/openmediavault/openmediavault/pull/2061

  • pre-release is NOT backports. pre-release is a repo in the omv repos. backports is a debian repo. There is no checkbox in the omv web interface to enable/disable backports. That is why I added buttons in omv-extras. OMV has had this behavior for over a decade.


    pre-release updates does not add the backports kernel (6.17). It just happened to update your apt cache. OMV enables backports by default. You can disable it from the command line or in omv-extras.

    Oh yeah, now I totally get what you're were saying.

    So in the end, OMV enables backports by default but doesn't run update/upgrade afterwards.
    From a user's perspective, you update/upgrade everything, then you install OMV... Assuming everything is up to date.
    But somehow, now there are new updates available. Isn't it a bit confusing?


    IMHO, the best experience would be achieved with one of these ways:

    • Don't enable backports by default, rely on omv-extras for it
    • OR, if doable, after enabling backports, run apt update && apt upgrade.

    Side question : still using "apt-get" ? Any reason for not using newer "apt"?


    This is only a problem insofar as it indicates that someone else has modified the configuration files. OMV is the master of the system, and the database is the source of truth. OMV only works in this direction; it does not synchronize configuration settings back to the database. Anyone looking for that functionality must resort to other products, such as Webmin.


    That isn't how configuration management works. The source of truth is not the config files. It is the database. saltstack just makes the config files match the database. If your config files don't match, then it is likely that you or another service changed them. Like the network table issue, it is showing what is in the database.

    Good to know how it currently works, thanks for clarifying. But I do believe we can do much more accurate and therefore better.


    Because currently, after a fresh install with 0 manual tweak made to the OS, one would assume OMV displays the truth (which is the initial state of the default network config), not OMV's default settings that aren't actually applied.


    At first glance, right solutions would be either:

    • Apply these OMV's default settings upon install, so they become true
    • Or, show a warning that these settings are default and not yet applied
    • Or, read the actual config and report back in OMV to display the actual config
    • Or, add a logic for enable/disable network management via OMV, and make it default to disabled, since that would be true

    I believe any of these could only make more sense to users. These kind of details avoid user doubts/questions and vastly improve the overall feel and experience.

  • This is documented here: https://docs.openmediavault.or…stallation/on_debian.html


    I was referring to the rrdcached syslog output rather than the DNS issue.

    Oh OK, so rrdcached was the actual Debian issue! I get it now.


    I see, I likely didn't have systemd-resolved installed by default on minimal Debian install.

    My mistake was following OMV8's topic but not initial linked doc to install resolved beforehand.


    I do believe there are ways to prevent breaking DNS resolving until reboot.
    I currently don't have enough technical knowledge about OMV's structure (and systemd-resolved) to propose a practical fix.

    But I've asked Claude and OpenAI and they had suggestions that may be usable.

    There may be a good idea that would totally fix this and avoid the need for this doc/warning/instruction.

    That would simplify documentation and install process (and avoid mistakes like the one I just made yesterday!).

    • Official Post

    But somehow, now there are new updates available. Isn't it a bit confusing?


    This only happens when you install OMV on Debian for amd64. If you use the OMV iso or install on an arm board, you won't have this issue. If you use the install script, you shouldn't have this issue either.

    Don't enable backports by default, rely on omv-extras for it

    You are trying to reverse something that was enabled after years of experience. The newer kernel is needed for hardware support on many systems.


    Side question : still using "apt-get" ? Any reason for not using newer "apt"?

    apt is slow.

    they do the same thing

    apt isn't meant for scripting or automation

    Because currently, after a fresh install with 0 manual tweak made to the OS, one would assume OMV displays the truth (which is the initial state of the default network config), not OMV's default settings that aren't actually applied.

    it does for most things. networking is the one thing it doesn't. The install script tries to add the network adapter to the database. So, this is only an issue on amd64 with debian install and not using the install script.

    Or, add a logic for enable/disable network management via OMV, and make it default to disabled, since that would be true

    since omv doesn't read the config, people can configure their networking outside of the web interface if they don't add anything to the database.

    omv 8.0.6-2 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.2 | compose 8.1.2 | cterm 8.0 | borgbackup 8.0.2 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Thanks for the feedback, I appreciate the care and dedication!

    This only happens when you install OMV on Debian for amd64.

    [..]

    So, this is only an issue on amd64 with debian install and not using the install script.

    In the end, do you actually want to polish Debian installation? Or do you consider these kind of inconveniences as the reason why there is a packaged distro in the first place? I could totally understand if this wasn't a priority at all.


    This only happens when you install OMV on Debian for amd64. If you use the OMV iso or install on an arm board, you won't have this issue. If you use the install script, you shouldn't have this issue either.

    You are trying to reverse something that was enabled after years of experience. The newer kernel is needed for hardware support on many systems.

    Well, if you were able to install the base Debian in the first place, then it means your hardware runs without newer kernels. Maybe don't enable backports by default when OMV is installed over a standard Debian, but keep it enabled for the fully package OMV distro then?

    Or if you keep backports, then run the apt-get update/upgrade afterwards?


    I'm not trying to undo stuff, just providing fresh, external, and somewhat picky feedback and suggestions!

    Quote

    apt isn't meant for scripting or automation

    Thanks, I didn't know that. Digging a bit into it, it makes sense.


    it does for most things. networking is the one thing it doesn't. The install script tries to add the network adapter to the database. So, this is only an issue on amd64 with debian install and not using the install script.

    Good news that it works in the packaged OMV distro. However, getting it to work with package install from Debian would be a plus.

    since omv doesn't read the config, people can configure their networking outside of the web interface if they don't add anything to the database.

    This is not a feature request, it's a bug report. Displaying wrong info is a bug, not a missing feature. In the end, the fix is potentially solved with just UI... Ideally better recognition of initial network config when OMV is installed over Debian.

    (I've used manual network configs with OMV in the past, so I surely know we can make our own config, but that's not what I'm talking about!)

  • openmediavault-filebrowser 8.0-4 : Got an error 500 at the end of install (reported by browser console + floating red message). Reinstall appears to also have triggered an error 500, though there was no visual clue in frontend, showed only in logs.


    Nginx logs (interestingly, error 500 is found in *acces.log rather than *error.log) :

    Install:

    openmediavault-webgui_access.log:192.168.1.89 - - [29/Nov/2025:13:09:04 +0100] "POST /rpc.php HTTP/1.1" 500 441 "http://192.168.1.10/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"

    Reinstall:

    openmediavault-webgui_access.log:192.168.1.89 - - [29/Nov/2025:13:14:47 +0100] "POST /rpc.php HTTP/1.1" 500 471 "http://192.168.1.10/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36




    dpkg.log (install):

    2025-11-29 13:08:57 startup archives unpack

    2025-11-29 13:08:57 install catatonit:amd64 <none> 0.2.1-2+b3

    2025-11-29 13:08:57 status half-installed catatonit:amd64 0.2.1-2+b3

    2025-11-29 13:08:57 status unpacked catatonit:amd64 0.2.1-2+b3

    2025-11-29 13:08:57 install openmediavault-filebrowser:all <none> 8.0-4

    2025-11-29 13:08:57 status triggers-pending openmediavault:all 8.0-9

    2025-11-29 13:08:57 status half-installed openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:08:57 status unpacked openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:08:57 startup packages configure

    2025-11-29 13:08:57 configure catatonit:amd64 0.2.1-2+b3 <none>

    2025-11-29 13:08:57 status unpacked catatonit:amd64 0.2.1-2+b3

    2025-11-29 13:08:57 status half-configured catatonit:amd64 0.2.1-2+b3

    2025-11-29 13:08:57 status installed catatonit:amd64 0.2.1-2+b3

    2025-11-29 13:08:57 configure openmediavault-filebrowser:all 8.0-4 <none>

    2025-11-29 13:08:57 status unpacked openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:08:57 status half-configured openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:09:03 status triggers-awaited openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:09:03 status triggers-pending openmediavault:all 8.0-9

    2025-11-29 13:09:03 trigproc openmediavault:all 8.0-9 <none>

    2025-11-29 13:09:03 status half-configured openmediavault:all 8.0-9

    2025-11-29 13:09:03 status installed openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:09:03 status installed openmediavault:all 8.0-9


    dpkg.log (uninstall):


    2025-11-29 13:14:10 startup packages remove

    2025-11-29 13:14:10 status installed openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:10 remove openmediavault-filebrowser:all 8.0-4 <none>

    2025-11-29 13:14:10 status triggers-pending openmediavault:all 8.0-9

    2025-11-29 13:14:10 status triggers-awaited openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:10 status half-configured openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:10 status half-installed openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:10 status config-files openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:10 startup packages configure

    2025-11-29 13:14:10 trigproc openmediavault:all 8.0-9 <none>

    2025-11-29 13:14:10 status half-configured openmediavault:all 8.0-9

    2025-11-29 13:14:11 status installed openmediavault:all 8.0-9

    2025-11-29 13:14:11 startup packages purge

    2025-11-29 13:14:11 purge openmediavault-filebrowser:all 8.0-4 <none>

    2025-11-29 13:14:11 status config-files openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:11 status triggers-pending openmediavault:all 8.0-9

    2025-11-29 13:14:11 status not-installed openmediavault-filebrowser:all <none>

    2025-11-29 13:14:11 startup packages configure

    2025-11-29 13:14:11 trigproc openmediavault:all 8.0-9 <none>

    2025-11-29 13:14:11 status half-configured openmediavault:all 8.0-9

    2025-11-29 13:14:12 status installed openmediavault:all 8.0-9


    dpkg.log (reinstall):


    2025-11-29 13:14:42 startup archives unpack

    2025-11-29 13:14:42 install openmediavault-filebrowser:all <none> 8.0-4

    2025-11-29 13:14:42 status triggers-pending openmediavault:all 8.0-9

    2025-11-29 13:14:42 status half-installed openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:42 status unpacked openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:42 startup packages configure

    2025-11-29 13:14:42 configure openmediavault-filebrowser:all 8.0-4 <none>

    2025-11-29 13:14:42 status unpacked openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:42 status half-configured openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:47 status triggers-awaited openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:47 status triggers-pending openmediavault:all 8.0-9

    2025-11-29 13:14:47 trigproc openmediavault:all 8.0-9 <none>

    2025-11-29 13:14:47 status half-configured openmediavault:all 8.0-9

    2025-11-29 13:14:47 status installed openmediavault-filebrowser:all 8.0-4

    2025-11-29 13:14:47 status installed openmediavault:all 8.0-9


    Additional details:

    The plugin seems to work after install.

    Other programs installs such as openmediavault-ftp 8.0-3 or openmediavault-hosts 8.0-2 didn't cause any error 500 upon install.

  • FTP server:

    I'm unable to login when SSL/TLS is enabled with a self-signed certificate.


    Filezilla shows:

    Status: Connecting to 192.168.1.10:21...

    Status: Connection established, waiting for welcome message...

    Response: 500 Sorry, no server available to handle request on ::ffff:192.168.1.10

    Error: Critical error: Could not connect to server


    Some useful system outputs:

    root@nas:/var/log# systemctl status proftpd

    proftpd.service - ProFTPD FTP Server

    Loaded: loaded (/usr/lib/systemd/system/proftpd.service; enabled; preset: enabled)

    Active: active (running) since Sat 2025-11-29 13:37:48 CET; 22s ago

    Invocation: c889eb6fcf604daaa4268b58f1d775ca

    Docs: man:proftpd(8)

    Process: 116359 ExecStartPre=/usr/sbin/proftpd --configtest -c $CONFIG_FILE $OPTIONS (code=exited, status=0/SUCCESS)

    Process: 116361 ExecStart=/usr/sbin/proftpd -c $CONFIG_FILE $OPTIONS (code=exited, status=0/SUCCESS)

    Main PID: 116362 (proftpd)

    Tasks: 1 (limit: 37538)

    Memory: 2.2M (peak: 3.8M)

    CPU: 30ms

    CGroup: /system.slice/proftpd.service

    └─116362 "proftpd: (accepting connections)"


    Nov 29 13:37:48 nas systemd[1]: Starting proftpd.service - ProFTPD FTP Server...

    Nov 29 13:37:48 nas proftpd[116359]: Checking syntax of configuration file

    Nov 29 13:37:48 nas proftpd[116359]: 2025-11-29 13:37:48,289 nas proftpd[116359]: mod_dso/0.5: unable to load 'mod_tls.c'; check to see if '/usr/lib/proftpd/mod_tls.la' exists

    Nov 29 13:37:48 nas proftpd[116359]: 2025-11-29 13:37:48,289 nas proftpd[116359]: fatal: LoadModule: error loading module 'mod_tls.c': No such file or directory on line 1 of '/etc/proftpd/tls.conf'

    Nov 29 13:37:48 nas proftpd[116359]: 2025-11-29 13:37:48,289 nas proftpd[116359]: warning: unable to include '/etc/proftpd/tls.conf': Operation not permitted

    Nov 29 13:37:48 nas proftpd[116361]: 2025-11-29 13:37:48,303 nas proftpd[116361]: mod_dso/0.5: unable to load 'mod_tls.c'; check to see if '/usr/lib/proftpd/mod_tls.la' exists

    Nov 29 13:37:48 nas proftpd[116361]: 2025-11-29 13:37:48,303 nas proftpd[116361]: fatal: LoadModule: error loading module 'mod_tls.c': No such file or directory on line 1 of '/etc/proftpd/tls.conf'

    Nov 29 13:37:48 nas proftpd[116361]: 2025-11-29 13:37:48,303 nas proftpd[116361]: warning: unable to include '/etc/proftpd/tls.conf': Operation not permitted

    Nov 29 13:37:48 nas proftpd[116362]: localhost.localdomain - ProFTPD 1.3.8c (maint) (built Sun Nov 9 2025 13:49:42 UTC) standalone mode STARTUP

    Nov 29 13:37:48 nas systemd[1]: Started proftpd.service - ProFTPD FTP Server.


    root@nas:/var/log# ls -l /etc/proftpd/tls.conf

    -rw-r--r-- 1 root root 390 Nov 29 13:35 /etc/proftpd/tls.conf


    root@nas:/var/log# cat /etc/proftpd/tls.conf

    LoadModule mod_tls.c

    <IfModule mod_tls.c>

    TLSEngine on

    TLSLog /var/log/proftpd/tls.log

    TLSProtocol TLSv1.2

    TLSRSACertificateFile /etc/ssl/certs/openmediavault-c699184e-b9a5-4c9f-8998-3043a6fb7e2c.crt

    TLSRSACertificateKeyFile /etc/ssl/private/openmediavault-c699184e-b9a5-4c9f-8998-3043a6fb7e2c.key

    TLSVerifyClient off

    TLSRenegotiate required off

    TLSRequired off

    </IfModule>



    Manual fix:


    root@nas:/var/log# apt install proftpd-mod-crypto

    Installing:

    proftpd-mod-crypto


    Summary:

    Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 2

    Download size: 770 kB

    Space needed: 1502 kB / 898 GB available


    Get:1 http://deb.debian.org/debian trixie/main amd64 proftpd-mod-crypto amd64 1.3.8.c+dfsg-4+deb13u1 [770 kB]

    Fetched 770 kB in 0s (13.3 MB/s)           

    Selecting previously unselected package proftpd-mod-crypto.

    (Reading database ... 46170 files and directories currently installed.)

    Preparing to unpack .../proftpd-mod-crypto_1.3.8.c+dfsg-4+deb13u1_amd64.deb ...

    Unpacking proftpd-mod-crypto (1.3.8.c+dfsg-4+deb13u1) ...

    Setting up proftpd-mod-crypto (1.3.8.c+dfsg-4+deb13u1) ...


    root@nas:/var/log# systemctl restart proftpd



    -> Problem is OMV doesn't install proftp-mod-crypto.

  • Using this:

    Code
    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

    It showed some errors regarding /var/cache/openmediavault/archives

    These errors showed twice in the process.


    After that, interface showed:

    Quote

    Please install the openmediavault-compose to provide docker functionality within the OMV web interface.


    So I ran apt install openmediavault-compose.


    Then OMV's interface shows :


    Quote

    Pending configuration changesYou must apply these changes in order for them to take effect.The following modules will be updated:

    • compose

    Applying changes results in an error:

    Code
    500 - Internal Server Error
    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LC_ALL=C.UTF-8; export LANGUAGE=; omv-salt deploy run --no-color compose 2>&1' with exit code '1': nas.mydomain.net: ---------- ID: configure_etc_docker_dir Function: file.directory Name: /etc/docker Result: True Comment: The directory /etc/docker is in the correct state Started: 16:11:20.773140 Duration: 0.706 ms Changes: ---------- ID: /etc/docker/daemon.json Function: file.serialize Result: True Comment: File /etc/docker/daemon.json is in the correct state Started: 16:11:20.773919 Duration: 2.242 ms Changes: ---------- ID: docker_install_packages Function: pkg.installed Result: False Comment: Problem encountered installing package(s). Additional info follows: errors: - No version matching 'docker-ce>=27.2.1' could be found (available: None) Started: 16:11:21.269941 Duration: 188.295 ms Changes: ---------- ID: docker_compose_install_packages Function: pkg.installed Result: False Comment: Problem encountered installing package(s). Additional info follows: errors: - No version matching 'docker-compose-plugin>=2.29.2' could be found (available: None) - No version matching 'containerd.io>=1.7.21' could be found (available: None) ...

    (reproduced 2 times)


    Reading this log made me tick "Docker repo" in omv-extras, which allowed applying changes without any further issue.

    • Official Post

    Reading this log made me tick "Docker repo" in omv-extras, which allowed applying changes without any further issue.

    Already documented in the appropriate place --> https://wiki.omv-extras.org/do…cker_compose#installation

  • Already documented in the appropriate place --> https://wiki.omv-extras.org/do…cker_compose#installation

    My point is: this could be automated instead of documented. Why make the user do what you can automate in 2 lines of code?

    Also... I didn't install docker compose in the first place, just omv extras. So I expected to have extra packages, not to be forced to install docker myself on top.

    I just followed these: https://wiki.omv-extras.org/ | OMV-Extras.org Plugin

    I may be tired (got a bad cold!) but I don't see any reference to docker compose here. So that may be an issue with OMV8.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!