I ran into a real weird behaviour of my OMV Server, and would like to get your opinion and experience before I dig deeper and maybe bother the community with a github issue.
Hardware - Homebuilt NAS Tower with 4 HDD Bays (currently 3 in use), one 120GB SSD as root disk, and one extra eSATA PCI Adapter for an external eSATA Docking Station (for external backup disks).
*-core description: Motherboard product: NM70I-1037U vendor: BIOSTAR Group *-firmware description: BIOS vendor: American Megatrends Inc. physical id: 0 version: 4.6.5 *-memory description: System Memory physical id: 8 slot: System board or motherboard size: 4GiB description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns) product: KHX1600C9D3/4GX vendor: Kingston physical id: 2 serial: 7813C461 slot: ChannelB-DIMM0 size: 4GiB width: 64 bits clock: 1600MHz (0.6ns) *-cpu description: CPU product: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz vendor: Intel Corp. physical id: 9 bus info: cpu@0 version: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz slot: SOCKET 0 size: 1363MHz capacity: 3800MHz width: 64 bits clock: 100MHz *-network description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@0000:03:00.0 logical name: enp3s0 version: 07 size: 1Gbit/s capacity: 1Gbit/s
I startet with a Debian Stretch installation and installed OMV manually following the guide, and finally updated to Debian Buster in August 2021. (I took my time, as I did not want to be early adopter this time ). I did not install any additional software, besides some linux tooling like the lshw package etc. No pihole or other stuff. This server has the only purpose to run my OMV.
I also updated OMV on the CLI and verified it on the web gui shortly after. Yes, I did a reboot.
I was running with the default configuration for the web gui, which means port 80 and 443.
Everything was fine, until I did a small stupid mistake. I created a folder on my root disk instead my backup disk, and synced backup data there, resulting in the root disk being 100% full. I did not realize it immediately as all the shared were still working fine, even after a reboot. I recognized something is wrong when I wanted to access the web gui and it was not accessible (Timeout). So I plugged in my screen to the NAS and saw a bunch of error messages when booting. The journalctl entries clearly pointed to the full disk. I found the full root disk and deleted the misplaced backup data, rebooted and did an apt-get update / upgrade and autoremove and cleanup, as this was my original intend.
All error messages that I saw disappeared and everything looked fine.
But weirdly enough, the web gui was still not accessible. I was assuming some side effect of the full disk, but now I think this is not the case.
I used omv-firstaid to reset the web gui configuration (IPv4, Port 80 and 443, http and https enabled, IPv6 disabled), but nothing changed.
The nginx service was up and running, and looked fine.
When having a look at netstat -a I saw that there are no ports 80 and 443 listening for IPv4. But there were entries for IPv6 listening, like :::443 and :::80.
A google search showed some results in which IPv6 interferred with the IPv4 configuration when using the same ports (weird). I checked with ifconfig -a and saw that my ethernet adapter had no IPv6 configured, but the localhost had still an IPv6 entry. To be sure I disabled IPv6 manually by creating /etc/sysctl.d/70-disable-ipv6.conf with the content: net.ipv6.conf.all.disable_ipv6 = 1 and activated and rebooted.
The IPv6 entry finally disappeared for localhost, but the web gui was still not there.
As another post mentioned a possible port conflict, I switched my https port to 9443 and http to 8080 just to give it a test.
The web gui worked!!!
Now I checked on this with multiple combinations of 80, 8080, 443 and 9443.
I can verify that nginx starts correctly, but it seems to get a conflict on port 80 and 443 and does not provide the web gui as a result. I was not able to find the conflict, but obviously there ist some. As I have written I do not have any other software running, and especially no other software that provides a web interface. My setup is stable for some time now, and everything worked fine, until I did the update and filled the disk right after it.
I did not activate the firewall on the OMV server and I am trying to access it from my regular windows Desktop which is located in the same network.
netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:netbios-ssn 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:hostmon 0.0.0.0:* LISTEN tcp 0 0 MyNAS.local:5357 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:sunrpc 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:http-alt 0.0.0.0:* LISTEN tcp 0 0 127.0.0.53:domain 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN tcp 0 0 localhost.localdom:smtp 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:microsoft-ds 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:9443 0.0.0.0:* LISTEN tcp 0 0 MyNAS.:microsoft-ds 192.168.1.20:49691 ESTABLISHED tcp 0 256 MyNAS.local:ssh 192.168.1.20:51950 ESTABLISHED tcp6 0 0 [::]:hostmon [::]:* LISTEN tcp6 0 0 [::]:netbios-ssn [::]:* LISTEN tcp6 0 0 [::]:sunrpc [::]:* LISTEN tcp6 0 0 [::]:ssh [::]:* LISTEN tcp6 0 0 [::]:microsoft-ds [::]:* LISTEN udp 0 0 127.0.0.53:domain 0.0.0.0:* udp 0 0 0.0.0.0:sunrpc 0.0.0.0:* udp 0 0 192.168.1.25:netbios-ns 0.0.0.0:* udp 0 0 MyNAS.lo:netbios-ns 0.0.0.0:* udp 0 0 0.0.0.0:netbios-ns 0.0.0.0:* udp 0 0 192.168.1.2:netbios-dgm 0.0.0.0:* udp 0 0 MyNAS.l:netbios-dgm 0.0.0.0:* udp 0 0 0.0.0.0:netbios-dgm 0.0.0.0:* udp 0 0 localhost.localdoma:323 0.0.0.0:* udp 0 0 0.0.0.0:42091 0.0.0.0:* udp 0 0 0.0.0.0:mdns 0.0.0.0:* udp 0 0 0.0.0.0:hostmon 0.0.0.0:* udp 0 0 0.0.0.0:40271 0.0.0.0:* udp 0 0 MyNAS.local:3702 0.0.0.0:* udp 0 0 22.214.171.124:3702 0.0.0.0:* udp6 0 0 [::]:sunrpc [::]:* udp6 0 0 localhost:323 [::]:* udp6 0 0 [::]:33320 [::]:* udp6 0 0 [::]:mdns [::]:* udp6 0 0 [::]:hostmon [::]:*
ifconfig -a enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.112 netmask 255.255.255.0 broadcast 192.168.1.255 ether b8:97:5a:6a:99:e9 txqueuelen 1000 (Ethernet) RX packets 46175 bytes 7811605 (7.4 MiB) RX errors 0 dropped 18824 overruns 0 frame 0 TX packets 15647 bytes 13455749 (12.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1000 (Local Loopback) RX packets 41209 bytes 16630725 (15.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 41209 bytes 16630725 (15.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
My questions are:
- Did anyone have the same experience?
- Do you have any idea about the root cause? What could possibly cause such a weird conflict?
- Am I blind? I do not see anything else using 443 or 80? So I assumed a port conflict. Any ideas what this can be?
I came to a point where I wanted to ask for your oppinion and help in investigating on this. I do not think this is an issue related to my full disk issue anymore, but rather something that got introduced with my last package update.
Edit: Removed typos and corrected formatting.