Lastest Firmwares break AD

[bike-discount]

There was a firmware update today but it did not fix the problem

[BruceWillEs]

Use anyone a DHCP server for the ip of the qnap?

[csira]

There was a firmware update today but it did not fix the problem

Same for me, the update didn't fix the problem

[MMnasbase]

Same sad situation here. The german technical Support also told me that there will be a fix in the newest firmware .
I had 4.3.5.0728 that broke AD and the binding was lost sometimes within two hours but at least 2 times a day. Binding per Interface works maybe 80 percent and is enough that the employes can work again.
BUT: sometimes it reads the database from the AD , shows Users and Groups but ALL credentials are lost!! So beside new binding per Interface i had to reset all credentials (takes maybe 20minutes- HORROR).
Where qnap stores the credential Database for the AD users? no idea? but saving would be a great thing if such a situation is present.

Now i join the Domain maybe 2 to 5 times a day and have a lot of angry clients.

Seeing what the firmware does: readme: "Unexpected error about DNS registration failure would appear when users joined the NAS to a domain and enabled WINS server" (Firmware 4.3.5.0756).
That did not fix my problem at all. Still the same kind of unbinding and rebinding through interface. Do not know why the support in germany was so sure that my problem is fixed in this firmeware. The readme seems to just notify, that the message was removed
I also had this message 2 or three times last week when i wanted to rejoin. After reboot or waiting it worked again to rejoin per interface.

sometimes there is a log entry when it fails:
[Error][ASNAS01] Win/Mac/NFS
NAS Name: NAS01
Severity: Error
Date/Time: 2018/11/06 15:10:37
App Name: Win/Mac/NFS
Category: Microsoft Networking
Message: [WIN/Mac/NFS] Failed to register the NAS in DNS.


The ssh command mentioned earlier DOES not work for me when the AD binding is broken, still no AD users after ssh command executed. I also made a cronjob job that checked the binding but FUNNY : it said all the time it is ok, even when it was lost!
/etc/init.d/winbind restart MAKES no difference at all

But that has a Logic because i guess it is REALLY a DNS solution problem from the QNAP that it looses connection to the AD and can not resolve it any more. So the error message is not false.

I tried:
removing the Trunk to just 1 port 10GB cable to the switch / upgrade Switch firmware / reboot AD server / giving Binding to another Network card with 1GB speed on the qnap (so seperate it from the user traffic).
Delete all DNS from everywhere in QNAP interface besides the one and only: the DC .

i am quite frustrated. beginning to write a batch script for deleting all Network volumes on the wi10 Machines and reconnect with local user from local QNAP User Datanbase ;-( So no AD anymore.
I already have enough problems with the clients.

PS: can anyone confirm that reverting to the latest 4.3.4 brings back AD stability OR is it broken from now on nevertheless which firmware to flash ???
Because going back schould be no big Problem even for the Data (i will try to handle Backup - sure) . But restore would be a long timeto run if the data get lost.
Tipps like reset NAS to Factory and so on: that do not help when there a 10TB Data on it. Would be a whole weekend work.
Besides:; the German Support also said: solved in the 4.3.5.0728 and in a new 4.4 (but for my TS-X73U-RP there is no 4.4 firmware till now to load).
Waitig another 2 -3 weeks is HORROR!!

[BruceWillEs]

Since I have entered ip-address and DNS servers fixed, without DHCP, and rebind to the DC by its ip-address it wokrs up to now for more then 6 hours.
Maybe this could be a workaround.

[BruceWillEs]

It is not solved by 4.3.5.0756, which is the latest available version for my TS-831XU.

Same sad situation here. The german technical Support also told me that there will be a fix in the newest firmware .
I had 4.3.5.0728 that broke AD and the binding was lost sometimes within two hours but at least 2 times a day. Binding per Interface works maybe 80 percent and is enough that the employes can work again.
BUT: sometimes it reads the database from the AD , shows Users and Groups but ALL credentials are lost!! So beside new binding per Interface i had to reset all credentials (takes maybe 20minutes- HORROR).
Where qnap stores the credential Database for the AD users? no idea? but saving would be a great thing if such a situation is present.
...

[MMnasbase]

yes i can definitely agree to this. My Station was all the time fixed ip adress and IPv6 turned off. Also DNS configured all right and removed all Google 8.8.8.8 or 9.9.9.9 or ISP dns from DHCP and also DNS settings.
Maybe that is why it keeps running mostly for hours not just minutes!

But at the End: Nothing helps.
DNS ist broken from time to time and because of that ist AD broken.
That is what i think. So the error message that DNS is not respnding schould not be that wrong. The DNS in the domain is working for everybody in the company but not for the QNAP.
So i guess that is the big problem. Do not konow what they changed here and what library or driver in the linux settings got "upgraded" but there has to be a guilty package in the upgrade.

[storageman]

So when authentication fails is DNS not resolving

"nslookup google.com" (or server)

What is in?
"/etc/resolv.conf "
"cat /etc/resolv.conf"

If you add domain server to this any difference?

[zitzl]

I can see 127.0.1.1 in the resolv.conf, not our normal DNS Server (Active Directory).

We have some strange problems since the firmware update:
-only a few AD Users can access the shares (all in the same /21 Network), the users who can´t access the shares although aren´t able to ping the QNAP
-all AD Users can access the shares if they are in WLAN (all in the same /24 Network)

[storageman]

I would have said if users can't ping the box it's game over. How is this a firmware/AD issue?

[bike-discount]

New firmware update this morning. Will keep you posted if it helped...

[csira]

New firmware update this morning. Will keep you posted if it helped...

The update to firmware 4.3.5.0760 didn't help, at least on my TS-251.

[MMnasbase]

i will give the new firmware a try, but i am a litte frustrated and think it will not help. MAybe i have some luck...

ok: just looked at the rlease notes: no hint about DNS or AD service. so i guess no help

Because of the questions what is going on: The ping to the NAS and to the AD works from any workstation in a 4 Switch environment (so no cabing problem).
The problem startet exactly with upgrading the firmware from a Dezember 2017 4.3.4 firmware version to the newest 4.3.5 End of September 2018 .
And when the binding is lost: Ping to AD etc works. So ping and Network is not the Problem. The DNS is the Problem and AD does not work without DNS!!!
And the DNS is broken from the QNAP site!! Because the Workstations still can resolve everything!

Only because there is assumptions that the Network could be guilty or anything else besides the QNAP

[MMnasbase]

AGAIN the question: did anybody give the revert to 4.3.4 a chance. I will give that a try if the newest keeps making troubles.
But since there are 14 TB of data that could be lost i am not very happy with that!
Also the support says that the risk for the data is minimal: if it fails they will not know that they have said that ;-( That s how it works like i know after two decades in business.
And i will do a backup but moving 14TB two times means lot of wasted work time

[MMnasbase]

And maybe for the ones who would help themselves at least with a local user: make a batch and execute the batch file once

Mine is like that:
kill old volume bindings -it is up to you to change the letters
i used the 192.168.1.27 for the NAS = fix ip
Funny i had to also delete this IPC$ that was also shown up with the commant "net use" and blocked new assignements because WIndows does not allow to connect to one ip with dirfferent users.

so disconnect Bindings, them make a permannet binding (mine where called Mitarbeiter and Support and Share on the NAS with 192.168.1.27), connected by localusername and pwduser - fill in yours.
type that into notepad and then save as text and change txt extension of file to bat:


Net use x: /delete
Net use y: /delete
Net use z: /delete
Net use \\192.168.1.27\IPC$ /delete
Net use x: \\192.168.1.27\Mitarbeiter pwduser /user:localusername /PERSISTENT:YES
Net use y: \\192.168.1.27\Support pwduser /user:localusername /PERSISTENT:YES
Net use z: \\192.168.1.27\Share pwduser /user:localusername /PERSISTENT:YES
exit