You are not logged in.
Hello everyone,
I run a homelab server with Arch Linux, and I wanted to expose a DLNA server using minidlna, but it's not working. The weird thing is that with the exact same steps I can get it working on my main computer.
I have deactivated pihole and other such services that could interfere with dlna, but still nothing.
When running `sudo ss -ulnp | grep :1900` i get
UNCONN 0 0 239.255.255.250:1900 0.0.0.0:* users:(("minidlnad",pid=201125,fd=5))On the other hand, when running `sudo systemctl status minidlna` i do get a problematic output, but I don't know what's wrong...
minidlna.service - minidlna server
Loaded: loaded (/usr/lib/systemd/system/minidlna.service; enabled; preset: disabled)
Active: active (running) since Fri 2026-07-03 10:54:59 CEST; 3min 11s ago
Invocation: c6cc403dcb654f998eaf308b89011ee2
Main PID: 201125 (minidlnad)
Tasks: 2 (limit: 18876)
Memory: 13.5M (peak: 14.5M)
CPU: 135ms
CGroup: /system.slice/minidlna.service
└─201125 /usr/bin/minidlnad -S
Jul 03 10:54:59 myuser systemd[1]: Starting minidlna server...
Jul 03 10:54:59 myuser systemd[1]: Started minidlna server.
Jul 03 10:54:59 myuser minidlnad[201125]: minidlna.c:1134: warn: Starting MiniDLNA version 1.3.3.
Jul 03 10:54:59 myuser minidlnad[201125]: minidlna.c:1182: warn: HTTP listening on port 8200
Jul 03 10:55:00 myuser minidlnad[201125]: upnphttp.c:1281: error: send(res_buf): Connection reset by peer
Jul 03 10:55:00 myuser minidlnad[201125]: upnphttp.c:1281: error: send(res_buf): Connection reset by peer
Jul 03 10:55:00 myuser minidlnad[201125]: upnphttp.c:1281: error: send(res_buf): Connection reset by peerWhat have I done wrong? What should I do?
Thanks in advance!
Last edited by Al4st0r (Today 09:03:00)
Offline
Jul 03 10:55:00 myuser minidlnad[201125]: upnphttp.c:1281: error: send(res_buf): Connection reset by peer
General network issue/instablity? minidlnad starting before the network is up? (though the PID is pretty high)
=> check the system journal for that.
Otherwise stop the service and run "minidlna -d" in debug mode.
Offline
Thank you for your answer!
MiniDLNA's service file requires network to be working before attempting to start. Network should be working fine as I am generally connected to the server via ssh.
In the system journal, `journalctl -xeu minidlna` i see the following:
Jul 03 13:12:24 myuser minidlnad[446]: minidlna.c:1134: warn: Starting MiniDLNA version 1.3.3.
Jul 03 13:12:24 myuser minidlnad[446]: minidlna.c:1182: warn: HTTP listening on port 8200
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:816: error: sendto(udp_shutdown=9): Network is unreachable
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:816: error: sendto(udp_shutdown=9): Network is unreachable
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:324: error: sendto(udp_notify=9, 172.20.0.1): Network is unreachable
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:324: error: sendto(udp_notify=9, 172.20.0.1): Network is unreachable
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:324: error: sendto(udp_notify=9, 172.20.0.1): Network is unreachable
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:324: error: sendto(udp_notify=9, 172.20.0.1): Network is unreachable
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:324: error: sendto(udp_notify=9, 172.20.0.1): Network is unreachable
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:324: error: sendto(udp_notify=9, 172.20.0.1): Network is unreachable
Jul 03 16:34:00 myuser minidlnad[446]: minidlna.c:199: warn: received signal 15, good-bye
Jul 03 16:34:00 myuser systemd[1]: Stopping minidlna server...
░░ Subject: A stop job for unit minidlna.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A stop job for unit minidlna.service has begun execution.
░░
░░ The job identifier is 231667.
Jul 03 16:34:00 myuser systemd[1]: minidlna.service: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ The unit minidlna.service has successfully entered the 'dead' state.
Jul 03 16:34:00 myuser systemd[1]: Stopped minidlna server.
░░ Subject: A stop job for unit minidlna.service has finished
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A stop job for unit minidlna.service has finished.
░░
░░ The job identifier is 231667 and the job result is done.Using `minidlnad -d` to try to run in debug mode results in the error: `[2026/07/03 16:43:36] minidlna.c:781: fatal: Bad user 'minidlna'.`. I have found a thread in the Manjaro forum with this error but it just goes back to the arch wiki lol. After following those instructions, i got `minidlnad` working, but it still isn't being discovered by my other devices.
What else should I check?
Offline
Jul 03 13:12:30 myuser minidlnad[446]: minissdp.c:324: error: sendto(udp_notify=9, 172.20.0.1): Network is unreachableip a; ip rdocker?
Offline
Well, I first wanted dlna as a jellyfin plugin to work (with jellyfin inside docker), seeing as how that didn't work, i installed minidlna as a docker container, which didn't work either, and now i'm just trying to get minidlna to work, without docker... I've started the thread when I was already on the dockerless dlna, but maybe the journal is prior to that...
Output of `ip a; ip r` is something like (real ip hidden and such):
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether d4:be:d9:2b:eb:9d brd ff:ff:ff:ff:ff:ff
altname enp0s25
altname enxd4bed92beb9d
3: wlp3s0b1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 08:ed:b9:2e:a0:dd brd ff:ff:ff:ff:ff:ff
altname wlx08edb92ea0dd
inet 192.168.0.3/32 scope global noprefixroute wlp3s0b1
valid_lft forever preferred_lft forever
inet6 fe80::6ea1:e0dc:7344:2b3b/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: br-5f6b1c4180bc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether f2:fe:89:a9:38:e8 brd ff:ff:ff:ff:ff:ff
inet 172.20.0.1/16 brd 172.20.255.255 scope global br-5f6b1c4180bc
valid_lft forever preferred_lft forever
inet6 fe80::f0fe:89ff:fea9:38e8/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
5: br-70a078418075: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 36:bc:37:c4:2e:6d brd ff:ff:ff:ff:ff:ff
inet 172.19.0.1/16 brd 172.19.255.255 scope global br-70a078418075
valid_lft forever preferred_lft forever
inet6 fe80::34bc:37ff:fec4:2e6d/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 0e:fd:4a:a2:2e:eb brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
7: br-35adc897fa09: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:9e:10:e3:f0:c5 brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-35adc897fa09
valid_lft forever preferred_lft forever
inet6 fe80::9e:10ff:fee3:f0c5/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
8: veth1d104c1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-35adc897fa09 state UP group default
link/ether 76:c6:c6:7e:cd:a8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::74c6:c6ff:fe7e:cda8/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
...
20: vethbf4a94b@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-35adc897fa09 state UP group default
link/ether 82:7e:70:ea:44:e8 brd ff:ff:ff:ff:ff:ff link-netnsid 10
inet6 fe80::807e:70ff:feea:44e8/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
default via 192.168.0.1 dev wlp3s0b1 proto static metric 600
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-35adc897fa09 proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-70a078418075 proto kernel scope link src 172.19.0.1
172.20.0.0/16 dev br-5f6b1c4180bc proto kernel scope link src 172.20.0.1
192.168.0.1 dev wlp3s0b1 proto static scope link metric 600Last edited by Al4st0r (Today 15:04:56)
Offline
Are you using docker for anything else or are all those virtual devices and bridges stale?
You can limit minidlna to specific interfaces (eno1, wlp3s0b1) - https://man.archlinux.org/man/extra/min … _interface but otherwise want to clean up the network setup (docker0 has no carrier)
Offline
Yes, I'm hosting various services on this server, all of them as docker containers, divided into three docker networks which correspond to the three bridges shown...
What do you mean with your second sentence? Do you mean i should limit minidlna to wlp3s0b1 to make sure that the dlna gets exposed to the wifi network instead of the other docker containers?
Ok, doing so kinda works... I've edited `/etc/minidlna.conf` and at least it removes part of the errors, now if i run `sudo systemctl status minidlna` i get:
● minidlna.service - minidlna server
Loaded: loaded (/usr/lib/systemd/system/minidlna.service; enabled; preset: disabled)
Active: active (running) since Fri 2026-07-03 17:44:36 CEST; 7s ago
Invocation: 76d1986a9a7c4c44a0e17395121bb7ee
Main PID: 40132 (minidlnad)
Tasks: 2 (limit: 18876)
Memory: 9.2M (peak: 11.1M)
CPU: 116ms
CGroup: /system.slice/minidlna.service
└─40132 /usr/bin/minidlnad -S
Jul 03 17:44:36 myuser systemd[1]: Starting minidlna server...
Jul 03 17:44:36 myuser systemd[1]: Started minidlna server.
Jul 03 17:44:36 myuser minidlnad[40132]: minidlna.c:1134: warn: Starting MiniDLNA version 1.3.3.
Jul 03 17:44:36 myuser minidlnad[40132]: minidlna.c:396: warn: New media_dir detected; rebuilding...
Jul 03 17:44:36 myuser minidlnad[40132]: minidlna.c:1182: warn: HTTP listening on port 8200
Jul 03 17:44:36 myuser minidlnad[40148]: scanner.c:731: warn: Scanning /opt
Jul 03 17:44:36 myuser minidlnad[40148]: scanner.c:820: warn: Scanning /opt finished (1 files)!
Jul 03 17:44:36 myuser minidlnad[40148]: playlist.c:135: warn: Parsing playlists...
Jul 03 17:44:36 myuser minidlnad[40148]: playlist.c:269: warn: Finished parsing playlists.Which would look correct except it says "warn" on each line? And it's still not showing up on other devices.
EDIT: my /etc/minidlna.conf looks like this now (i've remove the default comments that are in the file before posting it here):
port=8200
network_interface=wlp3s0b1
user=minidlna
media_dir=/opt
friendly_name=My DLNA ServerLast edited by Al4st0r (Today 15:49:42)
Offline
I'd not pay too much attention to the "warn" thing, does it work on the localhost (ie. can you access the dlna data from eg. a local vlc instance)?
Compare "ss -tulpen" on this and nmap from a host that's supposed to be a DLNA client, you earlier greeped for 1900/udp, make sure 8200/tcp is allowed, too.
Offline
The server doesn't actually have a desktop environment and i'd rather not add one for this... Here are the other two commands you mentioned...
When running `sudo ss -tulpen | grep minidlna`
udp UNCONN 0 0 192.168.0.3:41944 0.0.0.0:* users:(("minidlnad",pid=40132,fd=7)) uid:61737 ino:186504 sk:1001 cgroup:/system.slice/minidlna.service <->
udp UNCONN 0 0 239.255.255.250:1900 0.0.0.0:* users:(("minidlnad",pid=40132,fd=5)) uid:61737 ino:186500 sk:1002 cgroup:/system.slice/minidlna.service <->
tcp LISTEN 0 16 0.0.0.0:8200 0.0.0.0:* users:(("minidlnad",pid=40132,fd=6)) uid:61737 ino:186501 sk:2003 cgroup:/system.slice/minidlna.service <-> When running `sudo nmap -sU -sT -p U:1900,T:8200 192.168.0.3` i get:
Starting Nmap 7.99 ( https://nmap.org ) at 2026-07-03 17:55 +0200
Nmap scan report for al4st0rserver (192.168.0.3)
Host is up (0.000057s latency).
PORT STATE SERVICE
8200/tcp open trivnet1
1900/udp closed upnp
Nmap done: 1 IP address (1 host up) scanned in 1.26 secondsI find it weird in the second one that the 1900/udp port is labeled as closed? Is this the issue i have?
Last edited by Al4st0r (Today 15:58:12)
Offline
No, UPNP is closed outwards, that's fine.
What do you get on http://192.168.0.3:8200 ?
Offline
In a browser? Nothing. Sort of generic notfound error with title "Problem loading page" in firefox.
Offline
That would explain why you can't see anything but not why the webserver (ie. dlna) doesn't work respond - the port is obviously open (and I assume minidlna was still running at the time?)
curl -vL http://192.168.0.3:8200 > /tmp/wtf.txt 2>&1
cat /tmp/wtf.txt | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'Offline