psychofaktory

Members
  • Posts

    90
  • Joined

  • Last visited

  • Days Won

    1

psychofaktory last won the day on December 2 2022

psychofaktory had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

psychofaktory's Achievements

Apprentice

Apprentice (3/14)

16

Reputation

  1. Wow, many thanks for your tireless efforts. I'm stunned that so little attention has apparently been paid to the Samba configuration by the Unraid team for some time now. Hopefully your meticulous analysis will lead to better attention being paid to this issue in the near future and thus make the whole Samba integration under Unraid more reliable.
  2. Wenn ich diesen Post hier richtig verstehe zielt der dort genannte Workaround mit den beiden NICs auf Konstellationen mit MACVLAN ab. Also wenn z.B. die empfohlene Umstellung auf IPVLAN aus welchen Gründen auch immer noch nicht vollzogen werden konnte. In meinem Fall ist es aber so, dass ich bereits in Version 6.12.3 von MACVLAN auf IPVLAN migriert bin. Dabei gab es keinerlei Probleme. Erst mit dem Wechsel von Version 6.12.3 auf 6.12.4 traten die Probleme auf. Daher denke ich dass der Fehler mit der neuen Version hinzukam und der verlinkte Workaround hier nicht relevant sein sollte. IPVLAN auf MACVLAN zurückzustellen und gleichzeitig den Workaround mit den 2 NICs anzuwenden nur um die neue Version installieren zu können halte ich für nicht praktikabel. Da halte ich das Update auf Version 6.12.4 lieber weiter zurück. Zumal mir aktuell ohnehin kein freier NIC zur Verfügung steht.
  3. Vielen Dank für die Info. Dann hoffe ich, dass ein entsprechender Fix bald von offizieller Seite aus eingepflegt wird und zeitnah ein Update erscheinen wird.
  4. Konnte jemand den Bug zwischenzeitlich nachstellen bzw. wird bereits an einer Lösung gearbeitet? Tatsächlich ist das der Dealbreaker für mich 2 Unraid-Installationen von v6.12.3 auf v6.12.4 anzuheben. Das scheint tatsächlich ein Ansatz zu sein. Unter Unraid OS v 6.12.3 ist noch "EnableIPv6": true gesetzt und es wird auch eine Config für IPv6 ausgegeben wenn ich docker network inspect ausführe.
  5. Leider nicht. Habe inzwischen schon ein Downgrade auf v6.14.3 durchgeführt. Seitdem funktioniert wieder alles wie gehabt. Nein, diese Informationen werden seit jeher über die Router Advertisements meiner Firewall zugewiesen.
  6. Die Diagnostics habe ich dem Post angehängt: adl15-srv01-diagnostics-20230901-1103.zip Ja. Wobei der Bereich für die MacVLAN-Probleme ja nicht relevant sein dürfte da ich ja bereits in der Vorversion zu IpVLAN migriert bin und damit bis dato auch alles funktioniert hatte.
  7. Hallo, seit dem Update von v6.12.3 auf v6.12.4 können alle Container bei denen neben einer festen IPv4-Adresse auch eine feste IPv6-Adresse hinterlegt ist nicht mehr gestartet werden. Hier ein Beispiel von Adguard-Home: Command execution docker run -d --name='AdGuard-Home' --net='br0' --ip='10.10.10.2' --ip6='2003:a:bdce:ae10:0:10:10:2' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Unraid" -e HOST_CONTAINERNAME="AdGuard-Home" -e 'TCP_PORT_3000'='3000' -e 'UDP_PORT_53'='53' -e 'TCP_PORT_53'='53' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:3000]/' -l net.unraid.docker.icon='https://raw.githubusercontent.com/SiwatINC/unraid-ca-repository/master/icons/adguard.png' -v '/mnt/user/appdata/adguard_home/workingdir':'/opt/adguardhome/work':'rw' -v '/mnt/user/appdata/adguard_home/config':'/opt/adguardhome/conf':'rw' 'adguard/adguardhome' 1f248b027ddacacdfbe7b1c3ca84518c35938fa6cef35467bd4bddfeb43fb819 docker: Error response from daemon: user specified IP address is supported only when connecting to networks with user configured subnets. The command failed. In den Docker-Einstellungen ist für das Interface "br0" sowohl ein IPv4-Subnetz als Custom Network angelegt, als auch ein IPv6 Subnetz: IPv4 custom network on interface br0: Subnet: 10.10.10.0/24 Gateway: 10.10.10.1 DHCP pool: not set IPv6 custom network on interface br0: Subnet: 2003:a:bdce:ae10::/64 Gateway: DHCP pool: not set Diese Docker-Einstellungen sind ansonsten noch gesetzt: Docker version: 20.10.24 Docker directory: /mnt/user/system/docker/ Default appdata storage location: /mnt/user/appdata/ Docker LOG rotation: Enabled Docker custom network type: ipvlan Host access to custom networks: Disabled Preserve user defined networks: No Mit exakt diesen Einstellungen hat bis zur Version 6.12.3 alles hervorragend funktioniert. Durch Setzen der Einstellungen "Host access to custom networks" auf "Enabled" und "Preserve user defined networks" auf "Yes" konnte das Problem nicht behoben werden. Wie kann ich die betreffenden Container wieder mit fester IPv4 UND fester IPv6 Adresse starten?
  8. Beneath the setting in your proxy you need to add and configure the variables PHP_MEMORY_LIMIT and PHP_UPLOAD_LIMIT https://help.nextcloud.com/t/increase-max-file-size-on-official-docker-container-not-linuxserver/157748/2
  9. Yes, unfortunately, absolutely nothing has changed in the matter. @unraidster has worked out that there is a second error pattern, which I had already described here in the thread, that seems to overlap with the error pattern from the initial post here. I really hope that the Unraid team finally takes care of the matter!
  10. Thanks for the write up on this topic. It sounds like the exact same error pattern as I had described here: https://forums.unraid.net/bug-reports/stable-releases/6103-intermittent-smb-issues-after-6102-upgrade-r2028/?do=findComment&comment=20618 I also think that this is a different additional problem than the one mainly described here. I sincerely hope that the Unraid team will take the information you have provided and finally fix this bug. The bug has been known for several months now. And although this is a business issue, nothing has been done about it yet. Even more: it was even noted that the priority of the bug fix was set very low here. Especially for customers who use Unraid in a business environment, this is an absolute core function with the highest security relevance. The question of how many Unraid users use this function and would benefit from the bug fix is irrelevant. Therefore, immediate bug fixing should be absolutely in the interest of the Unraid team.
  11. Can anybody help me with this? Has anyone a working setup with guacamole docker an LDAPS with a Windows Domain Controller? I would also like to change the name of the guacamole printer in the RDP sessions. How could this be accomplished? I also noticed that the clipboard does not seem to work via RDP. What could be the problem here?
  12. That's not right! I applied the mentioned fix and the problems are still there, as I already wrote. What kind of reasoning is that, please??? When we chose Unraid, one of the most important criteria was support for AD connectivity. As far as I can tell from the documentation, there is no mention anywhere that this is a feature that is being neglected and may not work. If a feature is offered, then a developer should also make sure that it works. Otherwise at least a clear marking would be appropriate that it is an experimental feature or something similar. To distance oneself from it afterwards is a slap in the face for all those who - like us - relied on this feature. I can't understand the logic behind this statement. Are you telling us that the problem will not be fixed for the time being because it will be very difficult to fix, even though you know that it is a serious problem that affects enterprise customers in particular? Seriously? Shouldn't bugs be fixed primarily based on their severity? It may be that the AD feature is only used by a minority compared to the other features. But this minority are usually customers from the enterprise segment for whom a bug in this area is particularly critical. And even though it may be a minority compared to the other features, the absolute number of people affected is probably still quite high. The feedback here in the forum alone shows that.
  13. 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!