Error in network definition: Invalid MAC address
Describe the bug
OMV completely disables network access of the appliance, if it has network interfaces in its database which don't actually exist.
To Reproduce
The user can only create network interface entries by choosing from a drop-down menu of actually existing ones, but apparently, there can be cases where entries remin there even when they don't actually exist anymore on the system.
In this case, when deploying using salt (and I have to assume the same thing happens when I apply configuration from the UI) it generates phony config files for these ghost interfaces in /etc/netplan/, and the "netplan apply" step fails because the config file is invalid
Error in network definition: Invalid MAC address '', must be XX:XX:XX:XX:XX:XX
This leaves the actually existing interfaces unconfigured, thus the network connectivity is completely lost.
Expected behavior
OMV should check each network interface entry in its configuration, and generate config files only for those that actually exist on the system. Ideally, this should be reflected on the UI too.
Reference to Forum
This is an example of prior discussion of this issue, though in that thread they didn't reach the conclusion of what actually caused the problem in the first place.
openmediavault Server (please complete the following information):
- OS version: Linux nas 5.4.181-odroidxu4 22.02.1 SMP PREEMPT Sun Feb 27 08:55:42 UTC 2022 armv7l GNU/Linux
- openmediavault version: 6.0.17-1
I don't have time ATM to work on that, so contributions from the community, especially those companies that make money with OMV and do not contribute back, in form of a PR is welcome.
Well, sorry, I'm just some guy who uses (very gratefully) OMV on his home NAS. In any case, I'll see if I can get something done about this. Honestly, I'm not affected by this bug anymore, since I already painstakingly figured it out, and solved it through hacking my appliance's serial console. So, my approach was primarily to record the bug here, so that it can be solved for others who might get affected at some point.
@votdev this issue seems likely caused by violating main assumption "Note: openmediavault (like other NAS solutions) expects to have full, exclusive control over OS configuration" suggest to close issue.
Except that in this case, OMV does have exclusive control. I don't really think the removal of a physical network interface constitutes "OMV doesn't have exclusive control over OS config".
Keep this issue open, maybe someone is interested in having a look on it.
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
up
I'm using OMV6 as a proxmox VM and so my network card are virtuals. I've recently play a lot with those card and stumble on the same issue : omv-salt deploy run systemd-networkd was not able to fullyfill the Mac address.
I've not find the root cause but a workaround is to remove the 2 following lines
match:
macaddress: {{ mac_address }}
from the file /srv/salt/omv/deploy/systemd-networkd/files/ethernet.j2
and re-reun omv-salt deploy run systemd-networkd
This also mean that previous line {%- set mac_address = salt['grains.get']('hwaddr_interfaces:' + interface.devicename) -%} in ethernet.j2 was able to get the interface name but not the MAC of the network card
I've not find the root cause but a workaround is to remove the 2 following lines
match: macaddress: {{ mac_address }}from the file
/srv/salt/omv/deploy/systemd-networkd/files/ethernet.j2and re-reunomv-salt deploy run systemd-networkd
The workaround seems to fix your issue, but will break all other installations out there if these lines are removed.
This also mean that previous line
{%- set mac_address = salt['grains.get']('hwaddr_interfaces:' + interface.devicename) -%}inethernet.j2was able to get the interface name but not the MAC of the network card
Indeed, it seems Salt was not able to fetch the MAC address of the interface somehow.
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
This issue has been automatically closed because there has been no activity for 90 days. We are sorry that we haven't been able to prioritize it yet. Please feel free to reopen this issue or create a new one. Thank you!
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
This issue has been automatically closed because there has been no activity for 90 days. We are sorry that we haven't been able to prioritize it yet. Please feel free to reopen this issue or create a new one. Thank you!