iobroker mit Docker: Kann keine Ports mehr durchschleifen
-
host modus ist auch kein allheilmittel.
wenn er alle ports aller seiner container 1:1 auf den host mappet,
dann würde es doch auch im host mode einen konflikt geben?
im hostmode darfst dann auch keine container betreiben, bei denen 2 den gleichen port haben wollen. dann musst wieder im container konfigurieren.
ich habe da mehrere davon.er muss einfach mal alle ports, aller seiner container prüfen, das es da keine doppelten gibt bzw die dann auf andere auf dem host mappen
um wirklich safe zu sein, könnte er mit macvlan arbeiten. dann kommt kein port mehr im host oder mit anderen containern in konflikt, da dann der container eine eigenständige ip bekommt. allerdings muss man zu beginn dann ein wenig mehr konfigurieren. aber auch das ist bei buanet in einem seiner artikel beschrieben
-
ich hab das mal hierher verschoben, wurde langsam doch nerdig
-
@glasfaser: Nein, es gibt nur diesen Container. Ich hatte damals zuerst den Container im Hostmode installiert. Dann wurde mir hier empfohlen den Bridge Mode zu nutzen. Daher kommt vermutlich die Zahl 2.
Damals konnte ich ja problemlos beliebige Ports durchschleifen. Nur heute geht das plötzlich nicht mehr. Warum ist die große Frage.
Ich habe jetzt mal alle Einstellungen durchgesehen:
das verwirrt mich jetzt. Ich hatte den Container doch im Bridge Mode installiert, aber was ist das hier? -
@pingo
Das ist das interne Netzwerk deines Containers. Das wird bei jedem Container im Bridge Mode angelegt. Erst das Port Mapping holt den Netzwerk Verkehr dann da raus. -
@pingo
Damit man mit der Lösung hier weiterkommt:
Also ein Port ist auf dem Host schon belegt
Es gibt keine weiteren Container
Dann gibt es noch die Möglichkeit das ein anderer Dienst auf der synology den Port belegt
Um rauszufinden welche applikation das ist musst du eine Shell auf deiner synology aufmachen (also das eigentliche System und in keinem Container) und über die folgende Beschreibung mal schauen ob du was findest
https://www.cyberciti.biz/faq/what-process-has-open-linux-port/1883 müsste ja mqtt sein. Kann sein das da schon ein mqtt Server läuft?
-
@oliverio :
< root@buanet-iobroker2:/opt/iobroker# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:1882 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:12001 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:12002 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.11:41739 0.0.0.0:* LISTEN -
tcp6 0 0 :::8081 :::* LISTEN -
tcp6 0 0 :::8082 :::* LISTEN -
tcp6 0 0 :::8084 :::* LISTEN -
udp 0 0 0.0.0.0:1905 0.0.0.0:* -
udp 0 0 127.0.0.11:55611 0.0.0.0:* -
udp 0 0 0.0.0.0:6666 0.0.0.0:* -
udp 0 0 0.0.0.0:6667 0.0.0.0:* >Warum sind plötzlich die anderen durchgeschliffen Ports nicht mehr zulässig?
Wenn ich keinen neuen Port hinzufüge, kommt ja dieselbe Fehlermeldung beim Speichern. D.h. ich kann die damals durchgeschliffenen Ports quasi nutzen, aber ich könnte sie heute nicht mehr so eingeben:
Ich suche ja einen offenen Port für den MQTT Server. Vielleicht kann ich ja einen der durchgeschliffenen Ports dafür nutzen, auch wenn es die Fragestellung nicht löst?
-
@pingo sagte in iobroker mit Docker: Kann keine Ports mehr durchschleifen:
Warum sind plötzlich die anderen durchgeschliffen Ports nicht mehr zulässig?
Da ist was strubbelich bei dir .
Vorschlag :
Frisches Backup von ioBroker erstellen ( Backitup ),
Docker komplett aus dem Paketzentrum löschen und neu installieren .
Dann ein neues ioBroker Image ziehen und installieren ,Achtung VIS vor dem Backup einspielen installieren ( BUG )
-
Bitte nochmal mein Post lesen.
Du sollst die Befehle nicht IM Container ausführen
Und dort benötigen wird den Namen des Prozesses der den Port belegt -
@oliverio : Sorry. Das liegt an meinen nicht guten Kenntnissen der Thematik. Ist es so vielleicht richtig:
root@Diskstation920:~# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:143 0.0.0.0:* LISTEN 20977/dovecot
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6000/nginx: worker
tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN 722/docker-proxy
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 679/docker-proxy
tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 658/docker-proxy
tcp 0 0 127.0.0.1:914 0.0.0.0:* LISTEN 5917/fcgi-pm
tcp 0 0 127.0.0.1:915 0.0.0.0:* LISTEN 6179/httpd24
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 11463/ftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 8452/sshd: /usr/bin
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 11868/cupsd
tcp 0 0 0.0.0.0:1880 0.0.0.0:* LISTEN 762/docker-proxy
tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN 640/docker-proxy
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 14817/postgres
tcp 0 0 0.0.0.0:2010 0.0.0.0:* LISTEN 699/docker-proxy
tcp 0 0 0.0.0.0:8282 0.0.0.0:* LISTEN 620/docker-proxy
tcp 0 0 0.0.0.0:1883 0.0.0.0:* LISTEN 743/docker-proxy
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 6000/nginx: worker
tcp 0 0 0.0.0.0:8284 0.0.0.0:* LISTEN 601/docker-proxy
tcp 0 0 127.0.0.1:4700 0.0.0.0:* LISTEN 11551/cnid_metad
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 11450/smbd
tcp 0 0 0.0.0.0:4190 0.0.0.0:* LISTEN 20977/dovecot
tcp 0 0 127.0.0.1:512 0.0.0.0:* LISTEN 21178/termd
tcp 0 0 0.0.0.0:12001 0.0.0.0:* LISTEN 546/docker-proxy
tcp 0 0 127.0.0.1:161 0.0.0.0:* LISTEN 11020/snmpd
tcp 0 0 0.0.0.0:12002 0.0.0.0:* LISTEN 526/docker-proxy
tcp 0 0 0.0.0.0:3493 0.0.0.0:* LISTEN 21460/upsd
tcp 0 0 0.0.0.0:50022 0.0.0.0:* LISTEN 8452/sshd: /usr/bin
tcp 0 0 0.0.0.0:44871 0.0.0.0:* LISTEN 506/docker-proxy
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 582/docker-proxy
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 6000/nginx: worker
tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 564/docker-proxy
tcp 0 0 0.0.0.0:5001 0.0.0.0:* LISTEN 6000/nginx: worker
tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 5364/mysqld
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 11450/smbd
tcp 0 0 0.0.0.0:5357 0.0.0.0:* LISTEN 6000/nginx: worker
tcp6 0 0 :::80 :::* LISTEN 6000/nginx: worker
tcp6 0 0 :::21 :::* LISTEN 11463/ftpd
tcp6 0 0 :::22 :::* LISTEN 8452/sshd: /usr/bin
tcp6 0 0 :::631 :::* LISTEN 11868/cupsd
tcp6 0 0 :::443 :::* LISTEN 6000/nginx: worker
tcp6 0 0 :::3261 :::* LISTEN -
tcp6 0 0 :::445 :::* LISTEN 11450/smbd
tcp6 0 0 :::4190 :::* LISTEN 20977/dovecot
tcp6 0 0 :::3263 :::* LISTEN -
tcp6 0 0 :::3264 :::* LISTEN -
tcp6 0 0 :::3265 :::* LISTEN 12581/scsi_plugin_s
tcp6 0 0 :::515 :::* LISTEN 1/init
tcp6 0 0 :::548 :::* LISTEN 11550/afpd
tcp6 0 0 :::50022 :::* LISTEN 8452/sshd: /usr/bin
tcp6 0 0 :::5000 :::* LISTEN 6000/nginx: worker
tcp6 0 0 :::6281 :::* LISTEN 17419/img_backupd
tcp6 0 0 :::5001 :::* LISTEN 6000/nginx: worker
tcp6 0 0 :::139 :::* LISTEN 11450/smbd
tcp6 0 0 :::5357 :::* LISTEN 6000/nginx: worker
udp 0 0 0.0.0.0:5353 0.0.0.0:* 16976/avahi-daemon:
udp 0 0 0.0.0.0:44343 0.0.0.0:* 16976/avahi-daemon:
udp 0 0 0.0.0.0:3702 0.0.0.0:* 10620/synowsdiscove
udp 0 0 0.0.0.0:9997 0.0.0.0:* 8468/findhostd
udp 0 0 0.0.0.0:9998 0.0.0.0:* 8468/findhostd
udp 0 0 0.0.0.0:9999 0.0.0.0:* 8468/findhostd
udp 0 0 0.0.0.0:1900 0.0.0.0:* 17664/minissdpd
udp 0 0 0.0.0.0:36787 0.0.0.0:* 11830/synorelayd
udp 213248 0 0.0.0.0:68 0.0.0.0:* 9763/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 8145/dhclient
udp 0 0 172.18.0.1:123 0.0.0.0:* 8459/ntpd
udp 0 0 192.168.178.144:123 0.0.0.0:* 8459/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 8459/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 8459/ntpd
udp 0 0 192.168.178.255:137 0.0.0.0:* 17172/nmbd
udp 0 0 192.168.178.144:137 0.0.0.0:* 17172/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 17172/nmbd
udp 0 0 192.168.178.255:138 0.0.0.0:* 17172/nmbd
udp 0 0 192.168.178.144:138 0.0.0.0:* 17172/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 17172/nmbd
udp 0 0 127.0.0.1:161 0.0.0.0:* 11020/snmpd
udp6 0 0 :::5353 :::* 16976/avahi-daemon:
udp6 0 0 :::3702 :::* 10620/synowsdiscove
udp6 0 0 fe80::e44e:4aff:fe3:123 :::* 8459/ntpd
udp6 0 0 fe80::42:7aff:fea0::123 :::* 8459/ntpd
udp6 0 0 fe80::9209:d0ff:fe0:123 :::* 8459/ntpd
udp6 0 0 ::1:123 :::* 8459/ntpd
udp6 0 0 :::123 :::* 8459/ntpd
udp6 0 0 :::52099 :::* 16976/avahi-daemon: -
@glasfaser said in iobroker mit Docker: Kann keine Ports mehr durchschleifen:
@pingo sagte in iobroker mit Docker: Kann keine Ports mehr durchschleifen:
Warum sind plötzlich die anderen durchgeschliffen Ports nicht mehr zulässig?
Da ist was strubbelich bei dir .
Vorschlag :
Frisches Backup von ioBroker erstellen ( Backitup ),
Docker komplett aus dem Paketzentrum löschen und neu installieren .
Dann ein neues ioBroker Image ziehen und installieren ,Achtung VIS vor dem Backup einspielen installieren ( BUG )
Hmmh. Ich hoffe erst noch auf eine Lösung, die mir weniger Sorgen macht, als eine Neuinstallation. Wer weiß, was dann danach alles nicht mehr geht?
-
@pingo
Evtl hast du es selbst schon gesehen
Port 1883 ist bereits von docker Proxy belegt und gemappt
Da die synology Oberfläche nur einen Container anzeigt müssen wir nun direkt mit docker weitermachen
Bitte die Ausgabe vondocker ps -
@oliverio :
<CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b0f536221783 buanet/iobroker:latest "/bin/bash -c /opt/s…" 4 months ago Up 25 minutes (healthy) 0.0.0.0:1880->1880/tcp, 0.0.0.0:1883->1883/tcp, 0.0.0.0:2001->2001/tcp, 0.0.0.0:2010->2010/tcp, 0.0.0.0:8081-8082->8081-8082/tcp, 0.0.0.0:8088->8088/tcp, 0.0.0.0:8282->8282/tcp, 0.0.0.0:8284->8284/tcp, 0.0.0.0:9000-9001->9000-9001/tcp, 0.0.0.0:12001-12002->12001-12002/tcp, 0.0.0.0:44871->44871/tcp buanet-iobroker2 -
also es gibt wirklich nur einen container
und 1883 ist bereits mit diesem container gemappt.
dann wird es nur nicht angezeigt.evtl dann den hinweisen von buanet folgen und lieber portainer installieren und dann nur noch mit portainer den/die container administrieren
https://smarthome.buanet.de/2018/12/portainer-auf-der-synology-diskstation/
Erster Hinweiskasten -
Um den Port 1883 geht es gar nicht mehr . Der TE hat sich auf Seite 1 schon selber korrigiert .
Er meinte 1882. -
Das liest sich für mich, als nicht sehr erfahrener User sehr bedrohlich:
Aktuell läuft ja iobroker prima. Ich kann nur den MQTT-Server nicht nutzen.Gibt es keinen Weg, der weniger riskant als eine Neuinstallation oder die Portainerlösung ist?
Ist denn vielleicht einer der bereits durchgeschliffenen Ports frei und kann statt 1882 benutzt werden? -
@pingo said in iobroker mit Docker: Kann keine Ports mehr durchschleifen:
@haselchen: Sorry ich meinte 1882. Hab den Eingangspost editiert. Sorry
^
Manchmal muss man für die TEs mitdenken
-
du müsstest 1883 nutzen können.
der ist auf jeden fall vom container zum host gemappt.
was mich wundert ist, das im container 1882 als LISTEN aufgeführt ist.
gehe mal in deine mqtt konfiguration (adapter?) IM container und schaue ob du du da den falschen port eingetragen hast.die fehlermeldung würde ich nicht auf die goldwage legen. dsm nutzt im hintergrund auch nur den docker befehl. wenn nun eine fehlermeldung falsch interpretiert oder missverständlich ausgegeben wird, kann das schon sein.
ich sehe container richtig gemappt, aber imm container hört ein programm auf port 1882
da du schon einmal die beiden ports verwechselt hast und ich im internet für 1882 keine passende applikation gefunden habe (https://de.adminsub.net/tcp-udp-port-finder/1882 ist nur so ein zertifikatsservice den du wahrscheinlich innerhalb iobroker nicht einsetzt
), vermute ich das du da was falsch konfiguriert hast.
alternativ den mqtt adapter entfernen, iobroker durchstarten und dann mqtt wieder hinzufügen (mit dem richtigen port bzw weg lassen, da das eigentlich schon im default vorgegeben sein müsste) -
@pingo said in iobroker mit Docker: Kann keine Ports mehr durchschleifen:
Gibt es keinen Weg, der weniger riskant als eine Neuinstallation oder die Portainerlösung ist?
docker direkt auf der shell nutzen
portainer als container zu installieren ist nicht riskant -
@OliverIO: Das hat seine Richtigkeit, weil ich ja 1882 im Shelly Adapter eingetragen habe. Leider kann ich 1882 aber nicht durchschleifen. Siehe oben.
Kann ich denn vielleicht statt 1882 einen der bereits durchgeschliffenen Ports verwenden?
-
@pingo
und warum nicht den standard port?
dann musst du das bestehenede mapping 1883 erst mal wieder aufheben, da hat sich wohl was verhakt, evtl auch deswegen die fehlermeldung.
vor der bearbeitung der mappings den container am besten stoppen.
aber wie gesagt nochmal der hinweis auf den hinweis von buanet /er hat das nicht ohne grund geschrieben), ansonsten dann mal per discord direkt an ihn wenden (Andre buanet), da gibt es eine docker sektion und ich habe gesehen, das er dort auch mit anwesend ist
