psychofaktory

Thank you, that worked!

I continued to test and research. My guess is that the certificate needed for LDAPs was not added correctly to the java keystore. How to proceed with this docker for this? For LDAP, do you need to manually add the Docker variables as described here, or is customizing guacamole.properties enough for this container? I was also able to take the two parameters 'ldap-follow-referrals: false' and 'ldap-operation-timeout: 30' from these instructions. Is anything known about this? I would be grateful for any help!

Hello, I have a problem getting the LDAPS connection to an Active Directory to work. My environment looks like this: Windows Server 2022 as Domain Controller with a public domain name A Let's Encrypt wildcard certificate bound to the AD domain according to these instructions. A test with ldp.exe locally on the windows server can successfully establish an LDAPS connection. ApacheGuacamloe Docker with network type Custom br0 and the active variables OPT_MYSQL and OPT_LDAP In guacamole.properties the comments in the mysql entries have been removed. The LDAP entries were set according to official documentation As a test, the corresponding container environment variables for LDAP were also set analogously The certificate was exported from the domain controller according to these instructions and added to the Java certificate store The command curl -v ldaps://dc.subdomain.domain.tld:636 can successfully connect to the directory from the Docker console. Nevertheless, neither the users authorized via LDAP are listed in guacamole, nor is it possible to log in with them. In the log catalina.out only these two errors can be found: 13:14:06.191 [http-nio-8080-exec-6] WARN o.a.i.d.pooled.PooledDataSource - Execution of ping query 'SELECT 1' failed: The last packet successfully received from the server was 3,887,635 milliseconds ago. The last packet sent successfully to the server was 3,887,635 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem. 13:14:07.031 [http-nio-8080-exec-6] WARN o.a.g.r.auth.AuthenticationService - Authentication attempt from xx.xxx.xxx.xxx for user "DOMAIN\user" failed. Advanced logging for LDAP has been enabled on the DC. The event viewer shows these two entries when a logon attempt is made: Information: Internal event: The LDAP server returned an error. Additional Data Error value: 00000003: LdapErr: DSID-0C060679, comment: Error decrypting ldap message, data 0, v4f7c Warning: Internal event: An LDAP client connection was closed because of an error. Client IP: yy.yyy.yyy.yyy:51621 Additional Data Error value: 3 Das System kann den angegebenen Pfad nicht finden. Internal ID: c060672 Where is the error here or what have I overlooked here?

Many thanks for the tip about the bug report. The solution explained there sounded promising. I have applied it accordingly. Unfortunately, however, this resulted in some unattractive changes: the UNIX share permissions of all directories were changed to owner:administrator and group:domain-admins. Also those of the appdata directory. before, despite the domain connection, I could create local Unraid users and give them permissions on the share. However, after the adjustment, the locally created users no longer had access to the shares. when I then wanted to remove a locally created user and add it again, I unfortunately found that the user could no longer be added. I then wanted to leave the domain again in order to be able to rejoin it. However, I discovered that I could no longer leave the domain because the "Leave" button had no function. What a terrible mess with the SMB permissions once you have joined an AD! A real nightmare! Edit: I then reset the permissions as recommended by @mgutt. Now I was horrified to discover that the permissions of the share order under /mnt/user (without inheritance to the subfolders) were reset to owner:administrator and group:domain admins without my intervention.

Hello, I have the following constellation: A Unraid server is included as a member in a domain. Administrator" is specified as the "AD initial user". Domain-admins" is specified as the "AD initial group". With the application of the setting, all shares under /mnt/user are provided with the owner "administrator", the group "domain-admins" and the rights "rwxrwxrwx". In addition to the Unraid default shares, I have created a "Lehrer" share and a "Schueler" share. Only teachers should have write access to the "Lehrer" share. However, a service user "Scan" should be able to store files in the subfolder "Scan". Teachers should have write access to the "Schueler" share. Pupils should only see a sub-folder "General" to which they should have read rights, as well as see a folder for their own class and have write rights to it. At the same time, the shares are integrated as external shares in a Nextcloud docker. From Windows, I can then access the shares with the user "Administrator" and assign further permissions via "Properties" -> "Security". In the standard configuration, everyone has access everywhere. To restrict this, I change the group for the share "Lehrer" in Unraid to the AD group "Lehrer", and for the share "Schueler" to the AD group "Schueler". The rights are set recursively to "rwxrwx---". I then assign more granular permissions from Windows. With the SMB extras hide unreadable = yes access based share enum = yes I was able to activate the access-based enumeration and thus only display the folders for the users who have the corresponding permissions. Otherwise, however, the configuration only works to a limited extent. With this variant, the members of the AD group "Lehrer" do not have access to the share "Schueler". In addition, the shares can no longer be accessed in Nextcloud. If I change the group to "users", the shares can be accessed in the Nextcloud again. With this variant, however, students and teachers can no longer access the shares. If I remove the default users and groups from the security properties of the share in Windows, these permission entries always remain: If, for example, the AD group "Lehrer" is included in the "Lehrer" share with the "Change" authorisation, "Full access" appears instead of "Change" after "Apply". However, the teachers do not have access to the share. I have already made the request in the German-speaking part of the forum. You can find more information there: What do I have to configure so that the shares and the respective subfolders can be accessed from the defined AD groups as well as from Nextcloud Docker?

Hello, I have added some post arguments to my Nextcloud-Docker. && docker exec -u 0 Nextcloud /bin/sh -c 'echo "umask 000" >> /etc/apache2/envvars' && docker exec -u 0 Nextcloud /bin/bash -c "apt update && apt install -y libmagickcore-6.q16-6-extra && apt install -y smbclient libsmbclient-dev && pecl install smbclient && docker-php-ext-enable smbclient". When the container is updated manually, the post arguments are applied. But when the container updates automatically with the "CA Auto Update Applications" plugin, the post arguments are not applied. What is the reason for this and how can I ensure that the post arguments are reliably executed?

@mgutt wäre es in Ordnung wenn ich die Anfrage auch nochmals im internationalen Teil des Forums stelle um die Reichweite zu erhöhen? Es wäre wirklich wichtig, dass das sauber funktioniert.

Hello, I have added some post arguments to Docker. && docker exec -u 0 Nextcloud /bin/sh -c 'echo "umask 000" >> /etc/apache2/envvars' && docker exec -u 0 Nextcloud /bin/bash -c "apt update && apt install -y libmagickcore-6.q16-6-extra && apt install -y smbclient libsmbclient-dev && pecl install smbclient && docker-php-ext-enable smbclient". This makes the message about SVG support in the php-imagick module disappear. It also installs the smbclient I need for the external storage plugin. This works fine when creating the container as well as updating it manually. But when the container updates automatically with the "CA Auto Update Applications" plugin, the post arguments are not applied. What is the reason for this and how can I ensure that the post arguments are reliably executed?

getfacl /mnt/user/Schueler getfacl: Removing leading '/' from absolute path names # file: mnt/user/Schueler # owner: administrator # group: users user::rwx user:lehrer:r-x user:schüler:r-x group::rwx group:users:rwx group:administrator:rwx group:lehrer:r-x group:schüler:r-x mask::rwx other::--- Auch hier gleiches Verhalten. Weder Lehrer noch Schüler haben Zugriff auf die Freigabe. Nextcloud schon. Die Mitgliedsverhältnisse sehen so aus, dass alle Schüler Mitglied der Gruppe "Schüler" sind und alle Lehrer Mitglied der Gruppe "Lehrer". Scan ist ein eigenständiger Benutzer der keiner der beiden Gruppen angehört. Ich habe bei dem letzten Test bewusst noch nicht mit Share bezogenen rw-/ro-Gruppen gearbeitet, um die Struktur hier einfach zu halten und damit die Übersicht hier im Thread nicht verloren geht. Rein funktionell sollte es ja keinen Unterschied machen.

getfacl /mnt/user/Lehrer getfacl: Removing leading '/' from absolute path names # file: mnt/user/Lehrer # owner: administrator # group: users user::rwx user:lehrer:rwx user:scan:r-x group::rwx group:users:rwx group:administrator:rwx group:lehrer:rwx group:scan:r-x mask::rwx other::--- default:user::rwx default:user:administrator:rwx default:user:lehrer:rwx default:group::--- default:group:users:--- default:group:administrator:rwx default:group:lehrer:rwx default:mask::rwx default:other::---

Ich bin jetzt wie folgt vorgegangen: Als erstes habe ich die ACLs zurückgesetzt. setfacl -bn -R /mnt/user/ Dann über Tools > Docker Safe New Perms die Standard-Unix-Berechtigungen wiederhergestellt. Anschließend wollte ich unter Windows die Sicherheits-Berechtigungen für die Freigabe "Lehrer" wie gewünscht setzen. Zu dem Zeitpunkt haben die Prizipale "nobody", "users" und "Jeder" Vollzugriff. "Nobody" ist der Besitzer, was laut dem verlinkten Thread bzw. der Linuxserver-Anleitung wohl nicht so sein sollte. Nobody und Users hätte ich jetzt unangetastet in den Sicherheits-Berechtigungendort belassen, da die ja offensichtlich für die Nextcloud benötigt werden. Jetzt wollte ich also "Jeder" entfernen, und die Gruppe "Lehrer" mit Vollzugriff hinzufügen (nur Ändern wird ja von Unraid nicht unterstützt, bzw. automatisch auf Vollzugriff geändert). Beim Versuch zu Übernehmen heißt es dann aber "Sie müssen Administratorenberechtigungen angeben, um diese Attribute zu ändern". Aber auch mit Administratorenberechtigungen wird der Zugriff verweigert. Obwohl ich als "Administrator" nicht der Besitzer der Freigabe bin, und der Zugriff verweigert wurde, wurde "Jeder" dennoch aus den Sicherheitsprinzipialen entfernt. Damit verliere ich allerdings auch selbst den Zugriff auf die Freigabe. Somit bleibt mir also nur die Besitzübernahme der Freigabe. Von Windows aus wird mir das jedoch ebenfalls verweigert. Also setze ich "Administrator" über die Unix-Berechtigungen als Besitzer und erhalte somit wieder Zugriff und kann jetzt auch die gewünschten Berechtigungen vergeben. Dann der Test: Weder mit einem Mitglied der Gruppe "Lehrer", noch einem Mitglied der Gruppe "Schüler" kann auf die Freigabe zugegriffen werden. Nextcloud hat weiterhin Schreibrechte in dem Verzeichnis. Das Ergebnis stellt so ziemlich genau meinen Ausgangszustand dar bevor ich den Thread hier eröffnet hab. Die bis dahin gesammelten Erkenntnisse hatten mich dazu veranlasst dann zum Test die Unix-Gruppe "users" zu entfernen und dafür die Gruppe "Lehrer" hinzuzufügen. Die Lehrer konnten jetzt auf die Freigabe zugreifen, aber für Schüler sowie die Nextcloud war ein Zugriff nicht mehr möglich. Daher entstand meine Vermutung, nur Mitglieder der explizit angegebenen Unix-Gruppe haben Zugriff auf die Freigabe. Wenn ich das aus der Linuxserver-Anleitung bzw. dem Thread von 2015 richtig lese, dann war meine Vorgehensweise wohl grundsätzlich nicht verkehrt. Nur sollte eben eigentlich ein Zugriff auf die Freigabe möglich sein, sobald die ACLs unter Windows korrekt gesetzt wurden. An anderen Stellen sollte garnicht angesetzt werden müssen. Auch nicht zur Besitzübernahme. Wo liegt hier also der Fehler? Und wie wäre es richtig zu machen?

Ursprünglich bin ich nach der verlinkten Anleitung von Linuxserver.io vorgegangen. Dabei habe ich die ACLs auch wie dort beschrieben rein von Windows aus gesetzt. Das war aber so zu Beginn garnicht möglich, da "nobody" Besitzer war. Daher musste ich erst die Besitzrechte übernehmen. Dann war mir aufgefallen, dass mit dem Domänen-join die UNIX-Gruppe von "users" zu "Domain Admins" gewechselt wurde. Das war grundsätzlich für mich kein Problem. Als ich dann aber festgestellt hatte, dass jeder Zugriff auf die Freigaben hatte, habe ich über Windows die ACL "JEDER" entfernt. Damit wurde dann unter Unraid die UNIX-Berechtigung für "andere" ebenfalls entfernt (0777 zu 0770). In der Folge hatte ich von der Nextcloud aus keinen Zugriff mehr. Erst ab hier habe ich dann versucht die Berechtigungen von Unraid aus zum Test anzupassen um verschiedene Konstellationen auszuprobieren und auch um zu verstehen wie die Zusammenhänge aussehen und was im Hintergrund abläuft wenn Berechtigungen geändert werden. Das hatte ich zwischen den Versuchen auch immer wieder gemacht um immer wieder von einer einheitlichen Basis ausgehen zu können. Nichts desto trotz werde ich die von Dir empfohlene Vorgehensweise morgen 1:1 so nochmal umsetzen und dann testen und berichten. Danke schon mal für Deine Hilfe!

Nach dieser Anleitung bin ich bereits vorgegangen. Die zu erwartenden Ergebnisse spiegeln leider nicht die die ich tatsächlich gesammelt hab. In dem verlinkten Thread wird ja erwähnt, dass die UNIX-Berechtigungen egal wären. Es wurde "Domain Admins" gewählt. Wenn ich das so einstelle, dann haben auch nur Domain Admins Zugriff. Keine Lehrer, keine Schüler und Nextcloud auch nicht. Die Anleitung ist mittlerweile mehr als 7 Jahre alt und bezieht sich auf eine gänzlich andere Unraid-Version, eine gänzlich andere Samba-Version, und vermutlich Server 2012R2 wenn ich die Screenshots so ansehe. Ich vermute hier hat sich einiges geändert. Grundsätzlich wäre es aber wohl möglich so wie ich das gerne nutzen würde, oder war es zumindest mal. Meine Gegebenheiten sind: Unraid 6.10.3 (mit der standardmäßig dazu ausgelieferten Samba-Version 4.15.7) Windows 2016 Standard (mit aktuellem Patch-Level) Der Windows-Server ist gleichzeit Domänen-Controller Der Zugriff auf die Freigaben von Windows aus erfolgt über SMB 3.1.1 Domänen-Funktionsebene 2016 Nextcloud-Docker in der aktuellen Version Das habe ich bei den Anpassungen der Berechtigungen gemacht. Sogar mit Neustart. Allerdings waren die Änderungen an den Berechtigungen (sowohl UNIX als auch Windows-Sicherheit) in weiteren Tests direkt live wirksam für meine Test-User. Daher gehe ich davon aus, dass das evtl. garnicht erforderlich wäre. Im AD hatte ich aber auch keine Änderungen durchzuführen. Die User waren alle bereits in den Gruppen in denen sie sein sollten. Anstatt der RO-Gruppe habe ich nur "Schueler" und anstatt der RW-Gruppe habe ich "Lehrer". Die User sind immer Gruppen zugewiesen und in den Sicherheitseinstellungen der Freigaben werden ausschließlich Berechtigungen für Gruppen erteilt. Nie für einzelne Benutzer.

Das ist eine gute Frage. Was da genau im Hintergrund passiert kann ich leider nicht sagen. Nein, leider gibt es offenbar keine Grafische Möglichkeit hier etwas anzupassen. Was ich bisher in Erfahrung bringen konnte: Über die GUI kann ersteinmal nur die AD-Anbindung durchgeführt werden. Die Einstellungen für den SMB Benutzer Zugriff in den Freigabe-Einstellungen bleiben davon vollkommen unberührt. Dort lassen sich weiterhin nur die Zugriffsrechte für die Benutzer festlegen die über die Unraid eigene Benutzerverwaltung angelegt wurden. In der Unraid-Benutzerverwaltung, sowie auch sonst tauchen die AD-Benutzer und Gruppen nirgends auf. Die Einstellungen sind primär über einen Windows-Rechner innerhalb der Domäne vorzunehmen. Der Benutzer der für den AD-join verwendet wurde hat auf die Unraid-Freigaben standardmäßig Vollzugriff und kann somit zur Vergabe der Berechtigungen verwendet werden. Auf vorhandene Freigaben kann man dann den Besitz übernehmen und die Rechte wie gewünscht vergeben. Nur funktioniert das eben leider nicht so wie es soll, da die UNIX-Berechtigungen hier noch mit reinspielen und in der Praxis wohl nur Mitglieder aus AD-Gruppen Zugriff haben, die auch in der Gruppe sind die als Unix-Gruppe angegeben wurde. Oder man vergibt mindestens die Rechte r-x für "Andere". Somit ist selbst eine nur leicht komplexere Berechtigungsstruktur nicht möglich. Unterm Strich muss ich aktuell die UNIX-Rechte 0777 setzen, damit ein Zugriff von Windows für die verschiedenen Gruppen aus möglich ist und gleichzeit vom Nextcloud-Docker aus. Damit haben aber eben alle Vollzugriff. Auch die garkeinen, oder nur Lesezugriff haben sollen. Wenn ich dann unter Windows die Sicherheits-Berechtigungen für "JEDER" entziehe, werden auch die UNIX-Rechte auf 0770 gesetzt. Somit hat dann wieder nur die festgelegte UNIX-Gruppe Zugriff. Im Beispiel also entweder Schüler, Lehrer, oder Nextcloud. Alle anderen sind jeweils außen vor. Die Freigabe-Berechtigungen lassen sich von Windows aus übrigens nicht einstellen. Hier wird "JEDER" mit Vollzugriff angezeigt. Die Schaltflächen für Hinzufügen oder Entfernen sind ausgegraut. Wie kann ich denn dem Share mehrere Gruppen zuweisen? Die Zuweisung mehrerer Gruppen in den Sicherheitseinstellungen von Windows aus funktioniert zwar, aber effektiv wird der Zugriff dann wieder unterbunden weil in den UNIX-Berechtigungen nur eine Gruppe hinterlegt werden kann. Und über setfacl mehrere Gruppen zuzuweisen hat wie bereits erwähnt leider auch nicht zum Ziel geführt. Wo wäre das einzustellen? in den SMB-Extras? Wie müsste der Eintrag für Nextcloud dann aussehen?

Wie kann ich damit dann gleichzeitig eine Freigabe für Lehrer mit Schreibzugriff, für Schüler nur mit Lesezugriff und für Nextcloud mit Vollzugriff einrichten? Wie ist das in Unraid dann anzuwenden?

Das möchte ich eigentlich vermeiden. Zumal dadurch sicherlich andere Probleme entstehen werden, da Nextcloud neben den beiden genannten Ordnern auch noch auf andere Unraid-Freigaben zugreift, aud die nicht von Windows aus zugegriffen wird. Aktuell sind die Shares direkt im Nextcloud-Docker gemountet und dann über das External Storage Plugin als lokale Folder gemountet. Eine Einbindung über SMB wäre da wahrscheinlich deutlich weniger Performant. Wie müsste die SMB Config dann aussehen? Das Problem das bei allen Varianten generell auftritt ist, dass ich für die Unraid-Freigaben nur eine Gruppe hinterlegen kann und dann in den Berechtigungen nur r, w, x für diese Gruppe oder eben alle anderen setzen kann. Wenn die festgelegte Gruppe "users" ist, damit Nextcloud auf die Daten zugreifen kann, muss ich für "others" mindestens r und x setzen, damit die Windows-Freigabe für z.B. die Lehrer angezeigt wird. Dann können aber auch die Schüler die Freigabe einsehen. Und sowohl Schüler als auch Lehrer nur lesend zugreifen. Da muss es doch irgendeinen Lösung geben... Was ich auch schon probiert habe war die Gruppe auf "users" zu setzen und dann mit setfacl -m "g:lehrer:rwx" /mnt/user/Lehrer/ die Lehrer als zweite Gruppe zu hinterlegen. Das hat aber wohl leider nicht funktioniert, denn auch nach der Anpassung hatten die Lehrer keinen Zugriff.

Hallo, ich habe folgende Konstellation: Ein Unraid-Server ist als Mitglied in eine Domäne aufgenommen. Als "AD initialer Benutzter" ist "Administrator" angegeben. Als "AD initiale Gruppe" ist "domänen-admins" angegeben. Mit Anwendung der Einstellung werden alle Freigaben unter /mnt/user mit dem Besitzer "Administrator", der Gruppe "domänen-admins" und den Rechten "rwxrwxrwx" versehen. Neben den Unraid-Default-Freigaben, habe ich eine Freigabe "Lehrer", sowie eine Freigabe "Schueler" angelegt. Auf die Freigabe "Lehrer" sollen nur Lehrer Schreibrechte bekommen. Ein Dienstbenutzer "Scan" soll jedoch in den Unterordner "Scan" Dateien ablegen können. Auf die Freigabe "Schueler" sollen Lehrer Schreibrechte bekommen. Schüler sollen nur einen Unterordner "Allgemein" sehen auf dem sie Leserechte haben sollen, sowie einen Ordner für die eigene Klasse sehen und Schreibrechte darauf haben. Gleichzeitig sind die Freigaben als externe Shares in einen Nextcloud-Docker eingebunden. Von Windows aus kann ich mit dem Benutzer "Administrator" dann auf die Freigaben zugreifen, und über "Eigenschaften" -> "Sicherheit" weitere Berechtigungen vergeben. In der Standardkonfiguration haben erst einmal alle überall Zugriff. Um das einzuschränken, ändere ich in Unraid die Gruppe für die Freigabe "Lehrer" auf die AD-Gruppe "Lehrer", sowie für die Freigabe "Schueler" auf die AD-Gruppe "Schüler". Die Rechte werden jeweils rekursiv auf "rwxrwx---" gesetzt. Anschließend vergebe ich von Windows aus granularere Berechtigungen. Mit den SMB-Extras hide unreadable = yes access based share enum = yes konnte ich die zugriffsbasierte Aufzählung aktivieren und somit nur die Ordner für die Benutzer anzeigen lassen, für die auch eine entsprechende Berechtigung vorhanden ist. Ansonsten funktioniert die Konfiguration allerdings leider nur bedingt. Bei dieser Variante haben die Mitglieder der AD-Gruppe "Lehrer" dann keinen Zugriff auf die Freigabe "Schueler". Außerdem kann in der Nextcloud garnicht mehr auf die Freigaben zugegriffen werden. Ändere ich die Gruppe auf "users" kann in der Nextcloud wieder auf die Freigaben zugegriffen werden. Bei dieser Variante können allerdings Schüler und Lehrer nicht mehr auf die Freigaben zugreifen. Wenn ich die vorgegebenen Benutzer und Gruppen aus den Sicherheitseigenschaften der Freigabe in Windows entferne bleiben immer diese Berechtigungseinträge übrig: Wird dann bei der Freigabe "Lehrer" z.B. die AD-Gruppe "Lehrer" mit der Berechtigung "Ändern" mit aufgenommen, erscheint nach "Übernehmen" dann anstatt "Ändern" "Vollzugriff". Dennoch haben die Lehrer keinen Zugriff auf die Freigabe. Was muss ich konfigurieren, damit gleichzeitig von den definierten AD-Gruppen als auch vom Nextcloud-Docker aus auf die Freigaben sowie die jeweiligen Unterordner zugegriffen werden kann?

Got it working with this: https://hub.docker.com/r/icewind1991/notify_push/

Is there a docker-template for this already? Is there perhaps a possibility similar to this:?

Thank You. "ip -6 route" shows root@UNRAID:~# docker exec syncthing ip -6 route 2a00:XX:XXXX:1010::/64 dev eth0 metric 256 fe80::/64 dev eth0 metric 256 multicast ff00::/8 dev eth0 metric 256 default via 2a00:XX:XXXX:1010::1 dev eth0 metric 1024 default via fe80::a236:9fff:fe21:80ea dev eth0 metric 1024 expires 0sec The ping from OPNsense was sent from the same Interface in which the docker container is. So no firewall should block here. Firewall is set to "Allow anything to anywhere" for testing. Ping6 from router to other clients works. Ping6 from other clients to router works. Ping6 from other clients to other clients works. Ping6 from router to Dockers on OPNsense doesn't work. Ping6 from router to OPNsene-host doesnt't work. Ping4 from router to OPNsense works. Ping4 from router to Dockers on OPNsense works. So it seems to be a problem with Unraid. what else have i missed? is there still a special setting that I need to set somewhere? Edit: I looked at the routing table of the OPNsense and realized that something must have been wrong here. After a restart of the OPNsense everything works now as it should!

Yes, the other devices in the network are working without problems with IPv6 I have now taken out the fixed IP and set the router advertisements of the OPNsense from "Router Only" to "Assisted". The container has then also properly obtained an IPv6 address via DHCPv6 and SLAAC. root@UNRAID:~# docker exec syncthing ifconfig eth0 Link encap:Ethernet HWaddr 02:42:0A:0A:0A:0D inet addr:10.10.10.13 Bcast:10.10.10.255 Mask:255.255.255.0 inet6 addr: fe80::42:aff:fe0a:a0d/64 Scope:Link inet6 addr: 2a00:XX:XXX:1010::f/64 Scope:Global inet6 addr: 2a00:XX:XXX:1010:42:aff:fe0a:a0d/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2726 errors:0 dropped:0 overruns:0 frame:0 TX packets:2369 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:288585 (281.8 KiB) TX bytes:337658 (329.7 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:103 errors:0 dropped:0 overruns:0 frame:0 TX packets:103 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9928 (9.6 KiB) TX bytes:9928 (9.6 KiB) Pinging from Docker to the router via IPv6 is possible without problems (even with static IPV6 address). However, the other way around is not possible. Could it be that the container is missing the associated route? root@UNRAID:~# docker exec syncthing ip route default via 10.10.10.1 dev eth0 10.10.10.0/24 dev eth0 scope link src 10.10.10.13

I use OPNsense as router. There DHCPv6 with Router Advertismenents is active. Fortunately, my provider has assigned me a fixed IPv6 prefix. For the Docker I would like to use static addresses. For testing I tried to reach the Docker from the router via ping. The Dockers are also in different VLANs. Here are the settings:

What does the configuration has to look like if I want to assign a static IPv6 address for the container on a custom network? I have specified a static address, but I cannot reach the container at this address. root@UNRAID:~# docker exec syncthing ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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 valid_lft forever preferred_lft forever 2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 3: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN qlen 1000 link/gre 0.0.0.0 brd 0.0.0.0 4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 5: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1464 qdisc noop state DOWN qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 6: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 7: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 33: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP link/ether 02:42:0a:0a:0a:0d brd ff:ff:ff:ff:ff:ff inet 10.10.10.13/24 brd 10.10.10.255 scope global eth0 valid_lft forever preferred_lft forever inet6 XXXX:XX:XXXX:1010:0:10:10:13/64 scope global flags 02 valid_lft forever preferred_lft forever inet6 fe80::42:aff:fe0a:a0d/64 scope link valid_lft forever preferred_lft forever

Has somebody been able to get the Talk High Performance Backend with this container working? I've seen there is a docker image available: https://hub.docker.com/r/schklom/nextcloud-spreed-signaling-strukturag But I didn't figured out how to get that working togehter. Maybe someone knows how?

Could it be an option to run notify-push in a separate container?: https://github.com/nextcloud/docker/issues/1422#issuecomment-783671955