psychofaktory

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.

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.

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.

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.

@matty2k Ich denke das sind zwei gänzlich unterschiedliche Probleme.

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.

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.

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?

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

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!

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.

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?

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.

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!

The error still occurs with the current version 6.11.5. also extremely annoying: After every Unraid System Update the permissions on all share folders under /mnt/user/ are reset to 0777 (owner "administrator", group "domain-admins"). This causes problems especially with Nextcloud Docker every time! I guess @Luke_Starkiller doesn't mean that an EOS version of samba was used, but if the developers have already commented on why Unraid uses an outdated way of SMB configuration to map AD users, even though it has been explicitly unsupported by samba for more than 5 years.

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?

Even with the new version 6.11.2 the problems persist 😒

As far as I can tell, this problem was not caused by a Microsoft update, but by the upgrade to Unraid 6.10.2, which led to the discovery of some Samba configuration problems in Unraid. Furthermore, there are other projects that currently use Samba in a domain environment and do not have such problems. I therefore see the ball not in Microsoft's or the Samba developers' court, but rather in the court of the Unraid devs.

There is a workaround, but it did not solve the problem in all cases. In my case, the problem still exists. It has been going on for over 2 months now. For the business sector (where I would place Active Directory), this is an unacceptably long period of time. I very much welcome the fact that the topic of Active Directory now seems to be receiving more attention with the new forum area. However, I think it is more important to fix the urgent, still open problems instead of putting energy into new topics.

Multichannel is turned off here and was turned off all the time.

Unraid OS v6.11.1 -> still the same behaviour.

So there seems to be no difference to my configuration here. But why it isn't working as expected here? By the way, the problem still exists with the new Unraid 6.11 and Samba 4.17.0.

I still don't know what relevance it has that "getent group" only shows local Unraid groups, but because of this I have investigated further. I went through the tests as described in this article and found out that the Kerberos authentication does not seem to work: kinit Scan kinit: Configuration file does not specify default realm when parsing name Scan Based on this error message, I searched further and found that the default realm should be entered in the Kerberos configuration file under /etc/krb5.conf as described here. Could this be a potential solution?

So basically this is the same solution approach as presented here in the thread. I applied it like this. But that didn't solve my problem. The adjustments had even affected all share folders. How does Unraid differentiate between domain-related and non-domain-related?