Sonos in Docker

This is a well know issue with docker and upnp. The typical solution recommended even on the docker boards is to make sure all of your containers (not just OH) run on host network instead of bridge. In practice, I find that 1 container running in bridge mode is fine, but all the others need to be running in host. As soon as you have more than one bridged container, upnp wigs out. This is occasionally a headache as some containers make it difficult to modify the internal network ports (gogs was a PITA to change the ssh port). My system has been running fine like this for a while now so I haven’t looked into what the latest on the issue is.

Do you know if this is true for “one container” or “one bridge network”? I could imagine moving all containers to one bridge network and leaving OH4 on host. I’ve got ~30 containers running and most of them created a new network. Reducing that is maybe a good idea anyway. But I don’t necessarily want to change all of them to host.
But many start a service on port 8080 or 80, so using host network makes it complicated.

I’m reasonably certain that it’s just the number of containers and not the number of different networks, but I could be wrong.

It might be worth checking out the docker boards to see if there’s any better recent info on the issue.

Gitea makes this much easier now. I originally ran Gogs and gave up on it because it was so hard to keep up and configure. But recently was running low on RAM and dropped GitLab and decided to move to Gitea instead of back to Gogs. Apparently it’s a fork of Gogs but appears to be receiving more new development and features. And it takes up less than half the RAM and resources than GitLab does.

Yeah, I just moved over to Gitea myself a little while ago. I’m quite happy with it.

Tagging you as I see you had the same problem in this thread (now closed). Did you ever find a solution ?

I activated TRACE loglevel for jupnp and started a Scan for Sonos Things:

/opt/openhab/userdata/logs$ cat openhab.jupnp.TRACE.log | grep jupnp | head -n 20
2023-10-25 22:00:49.389 [TRACE] [org.jupnp.registry.Registry         ] - Maintaining registry...
2023-10-25 22:00:49.389 [TRACE] [org.jupnp.registry.Registry         ] - Executing pending operations: 0
2023-10-25 22:00:50.188 [TRACE] [.jupnp.controlpoint.ControlPointImpl] - Sending asynchronous search for: ssdp:all
2023-10-25 22:00:50.190 [TRACE] [g.jupnp.protocol.async.SendingSearch] - Executing search for target: ssdp:all with MX seconds: 3
2023-10-25 22:00:50.191 [TRACE] [org.jupnp.transport.Router          ] - Trying to obtain lock with timeout milliseconds '6000': ReadLock
2023-10-25 22:00:50.191 [TRACE] [org.jupnp.transport.Router          ] - Acquired router lock: ReadLock
2023-10-25 22:00:50.191 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.193 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /
2023-10-25 22:00:50.193 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.194 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.195 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /
2023-10-25 22:00:50.196 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.196 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.197 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /
2023-10-25 22:00:50.197 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.198 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.201 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /

It also sends messages on (my server IP), but I think it’s strange that it sends requests on all Docker interfaces too… Not sure what to make of that.

Hi @pgruetter,
i added to my opts these 2 parameters
(your main ip in there, and the correct eth-interface name which could be another on your site)
since then it was able to see my upnp devices. It was not possible with network host only.

Maybe this helps you.


Oh, never saw that before! Will try this weekend and report back. Thanks a lot!

:partying_face: :partying_face:
You can’t imagine how excited I am.
Don’t you just love IT: You can search for forever and not find a solution. And then you just need the right hint and it’s solved in 1 minute.

I can finally use my Sonos speakers as intended.

Thanks a lot!

1 Like

Interestingly, this did not seem to work for me. I don’t know what the difference is, but since my system runs just find on the host network without this, I’m not going to spend too much time trouble shooting it.

Still a good option to have since it appears to work in some cases.

Thank you very much!

This works for me as well on a Synology NAS with different Containernetworks and Openhab itself on host network so I’m finally able to decom my Raspberry Pi.
I use
1 Like

Hey all,

when I set some of my containers (influxdb, loki, grafana, prometheus) to host its working without any additional upnp settings but i want to try this setting


but how do i set it with openhab running with docker?

Try setting it as the EXTRA_JAVA_OPTS container environment variable like in these examples:

Merry christmas,

thanks for the link, really much in there i missed to read. I expected that the parameter has to be set in a service file.

Just works perfect with the 2 parameters

EXTRA_JAVA_OPTS: " -Duser.timezone=Europe/Berlin"

Finally i got my sonos online after long time :slight_smile:

1 Like

Could you please contribute by an enhancement of the following page in documentation ?

The corresponding page in Github to propose your change :


Let me know if you plan to update the readme. Else I could do it as well - as I consider it very valuable information. But it does not make sense if I do something that will conflict with your work.

1 Like

If you can that would be great as im quite busy with my kids these days.

fyi: I’ve updated

removed bug tag and added documentation and enhancement tags - as it is not a bug in the sonos binding or OH code in general.

I think that once the doc is updated that issue can be closed.


I am going to test this evening. I think it will work when jupnp network interface is specified