UPNP for DLNA?

[sos_nz]

I want to run a minidlna server, since I’ve got an old Oppo 203 which doesn’t play nice with SMB (limited to V1 and keeps needing a login password) or NFS (can’t detect my TrueNAS NFS share).

The Oppo is DLNA capable, and I’ve got that running on an HTPC and working with the Oppo.

However, I’d like to run minidlna as a custom docker app. I’ve got it up and running using Dockge and the following compose file:

services:
  minidlna:
    image: vladgh/minidlna
    labels:
      - com.centurylinklabs.watchtower.enable=true
#   network_mode: host
    container_name: minidlna
    ports:
      - 8200:8200 # DLNA server port
    volumes:
      - /mnt/tank/Media/Video:/media/Video
      - /mnt/tank/Media/Music:/media/Music:ro
      - /mnt/tank/Media/Photos:/media/Photos:ro
      - ./config:/config # Configuration files
    environment:
      - MINIDLNA_MEDIA_DIR=/media
      - MINIDLNA_FRIENDLY_NAME=MyMediaServer
      - MINIDLNA_MEDIA_DIR_2=A,/media/Music
      - MINIDLNA_MEDIA_DIR_3=PV,/media/Photos
      - MINIDLNA_MEDIA_DIR_4=V,/media/Video
    restart: unless-stopped
networks: {}

But the resultant dlna server isn’t detactable by any dlna capable clients on my LAN. I know this is because the docker container is in its own subnet. I’ve read that using host networking can overcome this (a recent post on Jellyfin in this board alluded to it: Setup DLNA Jellyfin), but how can I get this working for my minidlna container?

I run all my docker apps successfully under Dockge, using a bridge, br0.

I tried adding ‘network_mode: host’ to the compose, but then minidlna errors with:
'minidlna | minissdp.c:198: warn: Failed to add multicast membership for address 172.16.12.1"

[swc-phil]

@sos_nz

I tried adding ‘network_mode: host’ to the compose, but then minidlna errors with:
'minidlna | minissdp.c:198: warn: Failed to add multicast membership for address 172.16.12.1"

Can you provide more lines of this log?

[neofusion]

UPnP is not going to work with the default docker network.

That leads me to believe that you need to either set the container to use the host network or configure Plex for manual set up instead of UPnP.

Personally I find UPnP to be unreliable (and sometimes dangerous) and always use the manual option.

[sos_nz]

@swc-phil

Can you provide more lines of this log?

Here you go…this from Dockge’s terminal

minidlna  | minidlna.c:1134: warn: Starting MiniDLNA version 1.3.3.
minidlna  | minidlna.c:394: warn: Creating new database at /minidlna/cache/files.db
minidlna  | minissdp.c:132: error: bind(udp): Address in use
minidlna  | minissdp.c:84: error: setsockopt(udp, IP_ADD_MEMBERSHIP): Bad file descriptor
minidlna  | minissdp.c:198: warn: Failed to add multicast membership for address 192.168.94.94
minidlna  | minissdp.c:84: error: setsockopt(udp, IP_ADD_MEMBERSHIP): Bad file descriptor
minidlna  | minissdp.c:198: warn: Failed to add multicast membership for address 192.168.94.91

@neofusion

set the container to use the host network or configure Plex for manual set up instead of UPnP.

Yep, that’s my conclusion too…but I don’t know how to do that for a docker container, managed by the (official) Dockge app in TrueNAS. I don’t have or use Plex (?!). As mentioned above, I’m setting this up since my client is an Oppo 203 UHD player, which lacks modern networking, but can browse dlna just fine. I’ve got a minidlna server running perfectly on an Arch Linux HTPC, but I’d rather it run on my always-on TrueNAS box, if possible.

[LarsR]

If i remember correctly all you should have to add to your compose file would be

network_mode: "host"

so it should look like this

services:
  minidlna:
    image: vladgh/minidlna
    labels:
      - com.centurylinklabs.watchtower.enable=true
    network_mode: "host"
    container_name: minidlna
    ports:
      - 8200 # DLNA server port
    volumes:
      - /mnt/tank/Media/Video:/media/Video
      - /mnt/tank/Media/Music:/media/Music:ro
      - /mnt/tank/Media/Photos:/media/Photos:ro
      - ./config:/config # Configuration files
    environment:
      - MINIDLNA_MEDIA_DIR=/media
      - MINIDLNA_FRIENDLY_NAME=MyMediaServer
      - MINIDLNA_MEDIA_DIR_2=A,/media/Music
      - MINIDLNA_MEDIA_DIR_3=PV,/media/Photos
      - MINIDLNA_MEDIA_DIR_4=V,/media/Video
    restart: unless-stopped

Edit:
For hostnetworking you dont have to use port mapping.

[swc-phil]

@sos_nz

Here you go…this from Dockge’s terminal

Can it be that 1900 or 8200 ports are already in use on the host (it definitely can as long as you are running many containers on it)? sudo netstat -tulpn | grep "1900\|8200" to find out.

And I wonder why the IP subnet differs from the original post…

@sos_nz

running perfectly on an Arch Linux HTPC

Well, you can spin up a VM on truenas. Passing media lib to it won’t be straightforward and probably will require an smb/nfs share connect inside a VM. However, I suppose that you already made those configurations on your HTPC.

[sos_nz]

@swc-phil

Can it be that 1900 or 8200 ports are already in use on the host

Pretty sure they’re not, but still check, thanks.

@swc-phil

And I wonder why the IP subnet differs from the original post…

That’s because those were after I tried “network_mode: host”. I guess that showed it worked in so far as being on host networking.

[swc-phil]

@sos_nz

those were after I tried “network_mode: host”

I thought both should have been with host network mode. Otherwise, what is the point in posting this error?

If you have the same error with using the “standard” docker network and with using the “host” network, I do believe that the issue is within the container itself (or its configuration) and not with the network.

[LarsR]

You two realize that the compose file I posted works right? At least it was in my test deployment

[swc-phil]

@sos_nz

I tried adding ‘network_mode: host’ to the compose, but then minidlna errors with:
'minidlna | minissdp.c:198: warn: Failed to add multicast membership for address 172.16.12.1"

[sos_nz]

@swc-phil

Heh - yes, good spotting

I’m guessing that because host networking is working in the second example, but the multicast error persists that it’s more likely there’s an issue with the container.

As more info, my TrueNAS networking is set up with enp36s0 as the NIC on 192.168.94.94/24, with br0 attached as enx6efxxxxxxxxxx at 192.168.94.91/24.

Anyway, will try a different image and report back - thanks all!

[sos_nz]

@LarsR

You two realize that the compose file I posted works right? At least it was in my test deployment

Thanks Lars…I’ve used the exact same compose you posted (correcting for my actual mount paths), but it’s still coming up:

minidlna  | minissdp.c:84: error: setsockopt(udp, IP_ADD_MEMBERSHIP): Bad file descriptor
minidlna  | minissdp.c:198: warn: Failed to add multicast membership for address 172.16.12.1
minidlna exited with code 255

[swc-phil]

@sos_nz

As more info, my TrueNAS networking is set up with enp36s0 as the NIC on 192.168.94.94/24, with br0 attached as enx6efxxxxxxxxxx at 192.168.94.91/24.

Wait, does it mean that your truenas technically has 2 addresses in the same subnet? Is the GUI accessible on both IPs?
If that’s so, you should know that having 2 IPs in the same subnet is highly discouraged and can cause problems.

[swc-phil]

@sos_nz

Thanks Lars…I’ve used the exact same compose you posted (correcting for my actual mount paths), but it’s still coming up:

minidlna  | minissdp.c:84: error: setsockopt(udp, IP_ADD_MEMBERSHIP): Bad file descriptor
minidlna  | minissdp.c:198: warn: Failed to add multicast membership for address 172.16.12.1
minidlna exited with code 255

Hmm. So you did compose with the host network and yet obtained the internal docker ip…

Tbh, that Dockge’s networks: {} at the end really bugs me…

[sos_nz]

@swc-phil

Hmm. So you did compose with the host network and yet obtained the internal docker ip…

Yes, it appears so

@swc-phil

networks: {} at the end really bugs me…

Bugs me too. It gets added by Dockge automagically to the end of all my composed stacks.

@swc-phil

If that’s so, you should know that having 2 IPs in the same subnet is highly discouraged and can cause problems.

Thanks again - I’ll get on to sorting that out pronto I think it’s a workaround I used a while ago after an update (may have been from Bluefin to Cobra) lost my GUI access.

[sos_nz]

Right - I’m now down to a single NIC (enp35s0) and IP address for my TrueNAS box and an associated bridge (br0), which I use so my Home Assistant VM can access the TrueNAS host as storage.

Still can’t get the minidlna docker container to multicast using host network.

Screens of my network setup, in case any of you boffins spot something…

[LarsR]

I wonder if dockge is screwing you, because i used the compose file i posted and used the custom yaml function in the truenas gui to deploy the app and it would launch just fine. I could access it on hostip:port and would get to a basic info dashboard. It did not get a internal docker ip so i guess it deployed correctly with host networking.

[swc-phil]

@sos_nz

Screens of my network setup,

If you have your NIC (enp35s0) in a bridge with IP, the NIC itself shouldn’t have IP.

[sos_nz]

@swc-phil

If you have your NIC (enp35s0) in a bridge with IP, the NIC itself shouldn’t have IP.

Another good spot, thanks Yep, I was messing around with the bridge trying to see if that would work (it didn’t), so I’ve recreated the bridge properly again.

[swc-phil]

I’m not a network guy. For one, I’ve never used VLANs. However, I have some abstraction that helps me set them up inside my proxmox. Take these with a pinch spoon of salt:

1. When you create a bridge – it’s an equivalent of an unmanaged switch.
2. If you didn’t specify NIC or IP, this “switch” is still functional. For example, if you “connect” 2 VMs to this switch, they could “talk” to each other.
3. When you specify a port in the bridge – it’s an equivalent of an unmanaged switch having this exact port as its own. For example, if you have this port connected to a physical switch/router, your 2 VMs become accessible in your LAN.
4. When you specify an IP on the bridge – it’s the equivalent of your host being connected to this virtual unmanaged switch with this exact IP.

Hope this helps.

P.s. If network guys are reading this – critique is highly appreciated.