Posts by votdev

    So I have Pi 4 running just fine. When I tried to install OMV like I've done now I don't know how many times via

    wget -O - | sudo bash

    I get this error:

    OMV 6.x on RPi is waiting for a fix. Exiting...

    Anyone know what this is about?

    I think this is releated to this pull request:

    Please run omv-rpc -u admin 'FileSystemMgmt' 'getList' '{"start":0,"limit":-1}' | jq and post the output here.

    The problem appeared in the past if there is a duplicate entry of the column used to order. The ExtJS framework then simply filters the duplicate entries. But this should not happen, otherwise this would mean that there is a duplicate device file which is not possible.

    But it is nowhere forbidden. TrueNAS for example is also using forms inside mat-card.



    I am sure there are more projects using it the same way.



    - ...

    A mat-card is a styling component to show the user that this is a form. Why reinventing the wheel when mat-card can be used to separate a form from the rest of the page?

    The font size if overwritten by the omv-form-checkbox-wrapper

    This is done to adapt the look of the checkbox field hint to the default look of all other form field hints. It does not make sense to define a different font size for checkbox hints when all other form field hints are using a different one which is defined by the Material framework.

    I think this is a bug in the Material framework because all form field hints are reducing their font size if they are embedded in a mat-card.

    It seems so, but i didn't find it in the file that is installed by the package.

    Doesn't matter, we need to fix it either way.

    Please run omv-env get and verify that there is no OMV_COLLECTD_HOSTNAME listed.

    Force Salt to update its internal pillar data: omv-salt stage run prepare

    Finally rebuild ALL configurations: omv-salt stage run deploy

    OK, at some time you have tried to customize the environment variable OMV_COLLECTD_HOSTNAME because uname -n outputs the hostname. Please execute omv-env get | grep HOSTNAME and something like OMV_COLLECTD_HOSTNAME=`uname -n` should be displayed.

    Please run omv-env unset OMV_COLLECTD_HOSTNAME and omv-salt stage run prepare; omv-salt deploy run collectd to fix the issue.

    Now @ OMV 5 I se something really, really stupid... Someone has decided the drives added by GUI are called by uuid. What a stupid idea...

    Because labels have caused dozens of user request here in the forum and GitHub issue because users have plugged in multiple USB devices with the same label which broke their configuration. The main reason is that they are not that predictable like UUID. The forum moderators and devs were just tired of wasting our time with such support requests. The now used solution also enhanced the user experience because of less troubles. Finally the way how the mount path looks like is totally irrelevant for the end user because they should not get in contact if they use OMV via UI. The backend of OMV is implemented that way which makes less troubles because it uses predictable device names. They are not human friendly, but OMV is no human, and the UI provides human friendly information by trying to hide the predictable devices files wherever possible.

    I want to have clear (by label) content of my /etc/fstab: (again, like I had @ OMV4)

    In that case OMV is not the right solution for you. If you want to have full control over such things that are normally unimportant for the end user, then maintain your system via CLI manually.

    This is just awfull...

    I really think you should try another product like FreeNAS or XigmaNAS, maybe they fit your needs better.

    And finally i forbid myself this way of expression that you are using here. You are using an open source product that is made available to you free of charge and is maintained by people in their free time. Use it as it is offered to you or find something else.