[Unraid OS version 6.6.0-rc1 available]

Anyone upgrading from an Unraid version BEFORE 6.4, must read and follow the instructions here when upgrading to Unraid 6.6

@limetech best to add this note to the OT

[Unraid OS version 6.6.0-rc1 available]

Remove "dynamix.plg".

 

[Unraid OS version 6.6.0-rc1 available]

7 minutes ago, Benson said:

Same issue, previous was black theme.

 

Start in safemode and verify again

[Unraid OS version 6.6.0-rc1 available]

Which plugins are you using?

[Unraid OS version 6.6.0-rc1 available]

Try the following:

 

With Unraid 6.5.3 installed change the theme to "white" (as you probably already did)

Upgrade to Unraid 6.6.0-rc1 and the default white theme should be replaced by the new theme.

 

GUI is tested and confirmed to be working on all major browsers.

Firefox 61.0.2 is working fine.

[Unraid OS version 6.6.0-rc1 available]

The screen in your post above suggest the "standard" white theme isn't used.

Did you manually change the theme name in the past?

 

An unformatted screen may happen when a theme name is not recognized.

The default white and black themes are updated in Unraid 6.6 and should appear normally if they were used in an earlier version.

 

[Unraid OS version 6.6.0-rc1 available]

Which browser are you using?

[[6.5.3] No notification of disk rebuild (capacity expand)]

Difficult to say if this is a bug. How to reproduce?

 

Any notification in the history must have been sent out, that is how the current implementation works.

 

[Docker update doesn't check for wrong time]

It is mandatory to set the correct time on the system, preferably sync'd with NTP,  otherwise multipe functions are not guaranteed to operate properly.

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

4 hours ago, thomas said:

When will be the new RC ready to test it?

 

The typical answer is soon (tm).

 

LT doesn't provide a time table, and a next version is released when deemed ready by LT. Patience required

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

I have made an update which addresses this issue.

 

Instead of pinging the Google DNS server a wget spider test is done to NCSI (network connection status indicator).

This is the same method as used by Microsoft Windows to update the Internet status in the taskbar.

 

In the process a bit smarter implementation is done to keep hold of the current Internet access state, which speeds up the plugins page updating time.

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

Hehe, I work for an ISP.

 

Not allowing ping is against established net etiquette, I would file a complaint with my provider if they do. Security, yeah right, nowadays DDOS attacks are much more sophisticated 

 

Indeed some ISPs go force you to use their own DNS servers only, but that should not prohibit to ping Google, again I would shy away from such an ISP.

 

Thanks for your suggestions anyway. I see if I can come up with something fancy.

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

The current solution was implemented more than a year ago. Seeing this in perspective, it works 99.999% of the time.

 

I don't think we should design with the restrictions of China in mind. Not able to ping Google, probably also means not able to access Github.

 

The Windows solution takes up to several minutes before the status is updated. That is a too long wait when retrieving the plugins status information and people will feel it takes "forever" to get the information.

 

Ultimately I am looking for a non-intrusive solution working in the background without user intervention. The moment a user can make changes, it will go wrong, even when multiple warnings are given (disk FORMAT comes to my mind).

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

The source of the problem is the firewall.

 

If somebody decides to block any ping request on his firewall, no fail-over will ever work.

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

11 minutes ago, jonathanm said:

I realize it works properly 99.999% of the time, but can we at least have it be changeable if needed?

 

Actually the code is written with a variable, which defaults to 8.8.8.8

 

I am very hesitant to make this configurable for users, because it introduces a (huge) risk that people set this wrong.

When your firewall is set up properly there is no issue whatsoever,  but making it configurable increases the chance to nearly 100% of not working (yes, I know there are knowledgeable people out there).

 

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

ping was invented for these kind of circumstances.

 

It all comes down to proper firewalling.

In my case I block external DNS queries too and force my LAN clients to use my local DNS servers.

The gateway (firewall) is configured in such a way that a direct DNS qurey is not allowed, but ping or traceroute to the same address is permitted.

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

pinging a destination is very common practice, it is done because of speed and low overhead (you want to determine as quickly as possible whether internet access works).

 

pinging the first DNS server isn't reliable. This can be your local router and it may answer fine while no internet is present.

Resolving an domain name is both time consuming and a heavy duty task (compared to a ping).

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

8.8.8.8 and 8.8.4.4 are indeed "terminated" by your router.

 

The plugin update function of unRAID however has a built-in Internet alive check, which is done by pinging 8.8.8.8, before it downloads files.

 

Your "deny" rule interferes with this check and hence no download takes place, resulting in the status "unknown". It is unfortunate that you can not make this deny rule more exact and only deny DNS queries.

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

What is the result of (do this on your unRAID server)

traceroute 9.9.9.9
traceroute 1.0.0.1

Tip: you can also verify the same command with 8.8.8.8 and 8.8.4.4 as destination

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

I find this a strange way of denying. You tell your router that 8.8.8.8 and 8.8.4.4 is on your LAN, which may give unpredictable results.

 

Does your router have ACLs or firewall rules? The better approach is to put a restriction on the traffic from the LAN (=outgoing) and deny destination 8.8.8.8+port 53

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

I don't have a dd-wrt router, but how exactly are you denying DNS queries to 8.8.8.8 and 8.8.4.4 ?

 

DNS queries are always on port 53. Both UDP and TCP are possible. A rule which denies specific destination address(es) and specific port(s) would work best.

 

[[6.5.3] DNS settings not used when checking for new version of unraid and plugins]

All functions on unRAID make use of the network settings, there are no separate settings for checking for updates.

 

The command below will tell which DNS entries are used by unRAID (should match the network settings)

cat /etc/resolv.conf

Perhaps your router is blocking more than expected? Any logs on the router?

[[6.5.3] Docker and VM pages not updating]

Updating of docker or VM page works fine for me. How to reproduce?

 

What exactly do you mean by "image gets updated but the icon doesn't change"? The icon of a container stays the same (unless the author has changed it) and the only thing changing is the status indicator (running, stopped, updating).

 

You are sure there is no conflicting adblocker or antivirus program interfering with the GUI?

 

 

[[6.5.3] global disk utilization notifications not working]

1 hour ago, johnnie.black said:

And this is when the global settings for that disk stop working, I'm guessing because the blank values are overriding them.

 

Thanks for testing.

In the newer version any blank values will be surpressed in the file (it requires a re-apply of at least one individual setting).

 

[[6.5.3] global disk utilization notifications not working]

Sharp eye!

Yes this is a later release  but notifications part hasn't changed.