Domain controller restart requires domain rejoin on NAS Pro

[timallen]

On a morning after our DC (MS SBS 2008) reboots due to automatic updates, we arrive at work to find that no-one can access any shares on the NAS. We need to rejoin the domain (this morning we had to enter the wrong password, have it be unsuccessful, then enter the correct domain controller password). We then have to restore the share permissions from a config backup. After that, we are OK until next time our DC reboots.

This is a critical issue to us and is bringing into question our use of the NAS, which we only purchased within the last month or so, the issue has already happened twice, and results in significant productivity loss.

Assistance please?

Thanks, Tim Allen

Details of our NAS:

Model: ReadyNAS Pro Business Edition [X-RAID2]
Firmware: RAIDiator 4.2.15
Memory: 1024 MB [4-5-5-15 DDR2]

IPv4 address: 1: 172.16.1.12
IPv4 address: 2: Not Connected

Volume C: Online, X-RAID2, 2 disks, 70% of 1754 GB used

[mdgm]

Please don't post your ReadyNAS's serial number. If you wish to identify your NAS, you can do so by opening a tech support case and posting your case number.

[timallen]

Hi mdgm,

Why not? What's it hurt?

Anyway, anyone have any input into the actual issue? Would it be better if I open a case with Negear?

Thanks,
Tim

[mdgm]

The main reason would be that if you haven't registered your device, someone could register it using your serial number. You don't want that to happen. Also knowing the serial number poses a security risk in some circumstances.

This forum is a community forum visited by fellow users like myself, as well as some NetGear support personnel and the Jedi (i.e. senior members of the business unit at NetGear devoted to the ReadyNAS). Hopefully someone comes along and can answer your question. I'd suggest opening an online support case and posting your case number here. That way either the forum or support will answer your question first.

[timallen]

Makes sense now re the serial number.

Additional info to my issue:

We arrived at work this morning to find there was no connectivity to the NAS, however this time the circumstances were slightly different to the previous two.

1. There was no reboot of the DC overnight this time.
2. After re-entering the domain admin password and applying, the NAS still seemed to have the access permissions for each share set (ie which groups in the domain have access) when the domain info had refreshed. (Previously we had to reenter this info for each share.)

Additionally:

If I look in the event viewer on the domain controller (Windows SBS 2008), every half an hour I see a message like this:

DCOM was unable to communicate with the computer nas2.transtech.internal using any of the configured protocols.

This happens whether the NAS is working or not. This even happened during at least a week or two or continuous uptime.

I did wonder omehow the NAS is only communicating with the domain when I put the password in, then tries every half hour for some period of time, then gives up? Not sure this is right on the money,as why did it give up after 24 hours or so today whereas before has stayed connected for at least a week?

Anyway, things are looking a little less clear cut.

Anyone able to assist?

[Grievous]

Send me your logs, the info is in my signature.

[timallen]

Hi grievous,

I have sent the logs.

The problem happened againlast night, and again, the DC had been rebooted. So that seems to be at least proven - that if the DC reboots, we lose our domain connection and then noone can access anything when we get in to work the next morning.

The problem happened once with no reboot of the DC. In that case, I just put the password in again for the domain admin and reconnected, and all was OK.

In the case where the DC reboot overnight, all the security settings on the shares are missing and even after restoring the connection to the domain, we need to restore the share settings from a backup.

Hope you can shed some light on this.

Thanks
Tim

[Grievous]

I noticed that at 8:30 this morning(according to the timestamps in the logs) that there were a number of unsuccessful attempts to rejoin the domain, was there any specific reason for that? Because I'm seeing it regularly before every successful join.

Also, are your NTP server entries on the ReadyNAS directed toward your domain controller, or the detault netgear NTP servers?(under system -> clock)

[timallen]

NTP server 1 is the DC, NTP server 2 is netgear.

Regarding the unsuccesful attempts, it could just be that we are putting in the password wrongly, but I do also recall on one occasion it seemed to need the wrong password first, then the right password to actually re-connect (not sure conclusively on that one.)

I doubt with the last one it would have been put in wrongly more than once or twice though.

[Grievous]

Can you eliminate the netgear NTP server from the list?

[timallen]

Yes, seems possible. I've done this.

Is your thinking that the time is becoming our sync when the DC is down, hence making it unable to rejoin? If so, why wouldn't it become possible once the DC is up and the time re-syncs? Does it log time syncs on the NAS - maybe there is evidence to support/refute the theory?

I can try a reboot of the DC later today to see if this helps if you think worthwhile.

Thanks,
Tim

[Grievous]

Because with our current firmware, the NTP server only syncs every 4 hours, if it were to happen to do that while the domain controller is unavailable(unlikely, but possible), it would sync to the next one on the list, and if the domain controller isn't synced the same as the NTP server that the ReadyNAS is synced to and you have a time skew issue, you end up with problems.

The other thing to try would be to install the latest beta.

[timallen]

We reliably can reproduce the problem whenever the DC reboots, so the four hours things seems unlikely.

I'm not really keen on running beta in a production environment.

We really need to get this sorted as we're going to pull the pin and move to something else if the NAS can't sustain a domain connection.

Do you have any other ideas?

Tim

[Grievous]

Well the beta does include a number of updates, and you'd be bringing a non-working system to a working state with the risk of leaving a non-working system(based on your description) in it's current state, so that's up to you.

[TeknoJnky]

keep in mind though, if you got to 4.2.16 beta you can not go back to any earlier version, due to GPT partition changes