Posts by votdev

    This is not possible via UI, but you can add a custom netplan.io configuration.


    Create a file called /etc/netplan/mybond.yaml. It may look like this if your bond interface is called bond0.

    YAML
    network:
    bonds:
    bond0:
    transmit-hash-policy: layer3+4

    You may need to run netplan apply or reboot the system. Alternatively run omv-salt deploy run systemd-networkd if you want OMV to rebuild the whole network configuration.

    1/ /etc/network/interfaces is "empty" (managed by openmediavault)

    OMV uses netplan.io to configure the network. Drop a file to /etc/netplan/ according to their documentation.


    Example:

    /etc/netplan/myroutes.yaml

    Code
    network:
    ethernets:
    ens224:
    routes:
    - to: 10.88.0.0/13
    via: 10.x.x.x

    The rest is done by OMV. You may need to run netplan apply or reboot the system.

    2/ I read about a plugin I cannot find in the list

    It has been dropped in OMV5.

    I believe I have some hicup in my network configuration after my upgrade from 4 to 5:

    If I change the configuration of a network interface, e.g. by simply adding an IP adress for the default gateway, and then apply the configuration, I get the following error:

    Do you have any idea how to fix this problem?

    It seems you have a duplicate configuration entry for eno1. Use omv-firstaid to reset the network configuration.

    Just looking at the vsftpd conf i can see it does has chroot also has systemd start unit. votdev maybe could consider changing to vsftpd

    No, OMV will stay on proftpd. Switching to something different is too expensive. Various issues should have been fixed with the latest OMV release.


    @knireis didn't tell us which problems occur, so suggesting to switch the FTP software is not the right way. We should anaylse the problem at first.

    allwan Could you elaborate on how you have achieved that, please? I have two LAN adapters, which are configured individually. I tried and failed several times to link them. My problem was that apparently you have to delete the configurations in order to create the bond from scratch. But removing the configuration, I lost access to the web-ui. It's like a catch 22. I've seen reports working around that by installing WLAN adapters in addition, but could not get those to work either...


    As such, any advice appreciated!

    The problem will be fixed in openmediavault 5.5.1. Ethernet and WiFi devices can be used for bonding right after their configuration has been deleted. It is not necessary anymore to apply the changes before to make them visible in the bond dialog.

    Debian does not update to new major versions in a stable release. The latest version is only in the latest testing release or in the backport repository of a stable release (but this is not supported by OMV because of side effects that appear when newer versions have different configurations).


    I checked the smart.conf manual again and IMO it is a bug in smartmontools.


    Code
    cciss,N - [FreeBSD and Linux only] the device consists of one or more SCSI/SAS or SATA disks connected to a cciss RAID controller. The non-negative integer N (in the range from 0 to 15 inclusive) denotes which disk on the controller is monitored. In log files and email messages this disk will be identified as cciss_disk_XX with XX in the range from 00 to 15 inclusive. Please see the smartctl(8) man page for further details.


    In your case every disk as his dedicated device file, so there is no need to tell smartctl that it should request a special disk behind the HPA 'wall'. Which identifier should be used in the current situation, 0, 1, 2, ... i don't know it. You could try to use

    smartctl -d cciss,0 -x '/dev/sdc' if that works, but again, is 0 the correct identifier of the disk? In my understanding -d cciss,N is ONLY necessary if there is only one device file for the whole HPA and all attached disks are hidden behind that. In that case it is necessary to tell smartctl which disk is requested behind that wall, but only in that case. That's why i think it's a bug. You could open an issue for that at the smartmontools project, maybe this will enlight the problem.

    I stopped disabling predictive naming in the install script about a week ago - https://github.com/OpenMediaVa…c3e3c9d7ef68b89523eff1987


    Looking at the mac address stuff now though. I *really* don't want to have to switch to predictive naming though. I don't mind using whatever comes configured but switching would realistically require a reboot.

    Hmmm, but working around something that is a default nowadays produces problems like this. To me it looks like there is only a UDEV rule that is related for enabling predictable device names. If this is the case, UDEV rules can be reloaded at runtime without rebooting. Or is this also a kernel boot configuration issue?

    I think you are running into the same problem as another user here: RE: Trying to access SMART menu in the WebUI throw an error message


    IMO this is a bug in smartctl because if every disk of the HBA has a dedicated device file then there is no need to use the -d cciss,N command line argument, because this is only needed if there is only ONE device file for the whole HBA and you want to request the SMART info for a specific disk behind that 'wall'.


    Please execute the Python code mentioned in the link above, i'm interested in the result. But i bet that the result is None because the HBA is using the generic sd driver.

    Ha. OK...I will offer a donation to a crafty developer who can remove the GUI restriction...

    That does not help, this feature will NOT made it into OMV again. Use the CLI if you want to create a RAID on USB. After that you can manage it via UI as usual.

    That confirms my suspicions that the switch from predictable device names to ethX is the problem. To fix the problem the RPi images must use predictable device names.


    ryecoaaron IMO it seems to be inevitable to use predictable network device names on RPi.

    OMV prevents the creation of RAID on USB devices because we had many users with data loss because of that. Therefor OMV will not support RAID over USB.

    The problem is that OMV does not detect that /dev/sdc is part of a HBA and therefor doesn't append the necessary smartctl arguments. Maybe the detection must be improved:


    https://github.com/openmediava…torage/backend/sd.inc#L74

    https://github.com/openmediava…storage/backend/cciss.inc


    Could you please run the following interactively (as root user) and report the output?

    Code
    root@omv5box:/home/vagrant# python3
    Python 3.7.3 (default, Dec 20 2019, 18:57:59)
    [GCC 8.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import openmediavault.device
    >>> sd = openmediavault.device.StorageDevice("/dev/sdc")
    >>> sd.host_driver
    'sym53c8xx'
    >>>

    Following the thread i think this is a bug in smartctl because the device is accessible directly and not behind a CCISS HBA, thus it is not necessary to append the -d cciss,N argument.


    Lets see what you report, but IMO this is a bug in smartctl that can't be fixed by OMV.