Posts by belegdol

    jata1, it looks like router setting the domain to fritz.box cannot be disabled.


    In the meantime, I have checked what my rpi running Raspbian 11 is doing. It can too resolve mDNS names, which makes router causing trouble increasingly unlikely, given that 3 devices can work with .local hostnames and one cannot. But then Raspbian 11 does not use systemd-resolved.

    I will try downgrading systemd-resolved to see if it helps.

    This fritz.box domain name could indeed be the culprit. Unfortunately, there seems to be no way of turning this off. Here is the nmap output from the laptop:

    Code
    $ nmap -sP 192.168.0.0/24
    Starting Nmap 7.92 ( https://nmap.org ) at 2024-11-29 21:52 CET
    Nmap scan report for fritz.box (192.168.0.1)
    Host is up (0.0041s latency).
    Nmap scan report for odroidxu4.fritz.box (192.168.0.14)
    Host is up (0.0033s latency).
    Nmap scan report for snowball3.fritz.box (192.168.0.21)
    Host is up (0.00072s latency).
    Nmap scan report for raspberrypi.fritz.box (192.168.0.245)
    Host is up (0.0078s latency).

    This is from the desktop:

    Code
    $ nmap -sP 192.168.0.0/24
    Starting Nmap 7.92 ( https://nmap.org ) at 2024-11-29 21:55 CET
    Nmap scan report for fritz.box (192.168.0.1)
    Host is up (0.00039s latency).
    Nmap scan report for odroidxu4.fritz.box (192.168.0.14)
    Host is up (0.0019s latency).
    Nmap scan report for napoleon2.fritz.box (192.168.0.68)
    Host is up (0.00018s latency).
    Nmap scan report for raspberrypi.fritz.box (192.168.0.245)
    Host is up (0.0024s latency).

    And this is from the NAS:

    Code
    $ nmap -sP 192.168.0.0/24
    Starting Nmap 7.93 ( https://nmap.org ) at 2024-11-29 21:55 CET
    Nmap scan report for fritz.box (192.168.0.1)
    Host is up (0.0016s latency).
    Nmap scan report for odroidxu4.fritz.box (192.168.0.14)
    Host is up (0.00030s latency).
    Nmap scan report for raspberrypi.fritz.box (192.168.0.245)
    Host is up (0.0011s latency).

    So it looks like Fedora systems can understand that foo.local is the same as foo.fritz.box and still resolve it, but OMV cannot. /etc/nssswitch.conf files differ somewhat. Fedora:

    OMV:

    Doesn't look like it has helped. I ran the command above, rebooted the NAS and it still cannot resolve the .local mDNS names. Strangely enough, my Android phone, my laptop and my desktop (latter two running Fedora 41) can all resolve mDNS names, including the one of the NAS. What I have noticed, however, is that when I ping odroidxu4.local from my laptop, the hostname being shown is odroidxu4.fritz.box. I have switched ISPs recently and now have to use fritzbox as a router. Could it be that it's builtin DNS server interferes with mDNS, and Fedora can deal with it whereas Debian cannot?

    Hello,


    I have recently realised that mDNS resolution is no longer working on my NAS. As a result, the scheduled print job I have set up to keep my printer from drying out can no longer find the printer. I am not sure if the error comes from debian, armbian or omv. In this time debian 12.8 update landed. `avahi-browse` finds the machines, but `ping` or `ssh` do not. I tried running `omv-firstaid`and reconfiguring the network but it did not help either. Here is the output of `resolvectl status`:

    And here is nssswitch.conf:

    Allegedly libnss-mdsn and systemd-resolved can interact in mysterious ways but I am not sure where to look next. Any help is appreciated.

    Hello,


    I am wondering how to set up my OMV to play music via a DAC connected to USB port on the NAS - youtube music in particular. I have now managed to get it working via mpv by running `nohup mpv foo &` and disconnecting, but this leaves me with no control over the player. Is there a cleaner way which is also not overly complicated? Something like a web UI to the music player? Thanks!

    I have now installed the updates using `apt upgrade`. But this is hardly a working long-term solution.

    Thanks for the tip, but I decided to take a more directed approach. Inspecting the journal revealed the following:

    Quote

    Mar 05 14:12:10 sshd[6543]: User xxx from 192.168.0.180 not allowed because none of user's groups are listed in AllowGroups.

    It turns out /etc/ssh/sshd_config still had ssh in it, not _ssh. I changed it to _ssh and now I am able to log in again. Shouldn't omv-release-upgrade have taken care of that? Or was it scheduled to be fixed, but after the step that failed due to checksum mismatches?

    Running

    Code
    omv-salt deploy run phpfpm
    omv-salt deploy run nginx

    has restored the OMV web GUI. I have clicked on the yellow "Apply changes" button. Looks good so far. Now I only need to figure out why my user login is not working.