At some time in the recent past (probably around the time of v6.1.3 upgrade), my Dashboard has been missing most data.  I suspect that this problem is only affecting me, since I cannot find any other reports.  I was hoping that the v6.1.4 upgrade might resolve the issue, but it hasn't.  I have tried booting up in 'Maintenance' mode, but that makes no difference (apart from Docker and Shares list data not being available) - I presume that this exonerates dockers/plugins.

 

The missing info is:

  All the disk statistics.

  The CPU speed statistics.

  The fan speed statistics (although fan speed is reported in the footer bar)

  The network statistics.

 

I attach a syslog and a screen shot.

 

Any suggestions as to what is going wrong here?

tower-syslog-20151118-0932.zip

SAFE mode

Safe Mode - of course, you're correct ... it must have been a lapse of my ageing brain!

 

Anyway, it turns out that my problem appears to be down to the browser/configuration.  If I access the web gui from another machine, running a different (ubuntu-based) distro, but still using Firefox, then all is well.

 

My main desktop machine, which is the one exhibiting this problem, is running Arch Linux and Firefox 42.0.

 

I'm not aware of problems in any other web gui pages/tabs - just the missing data on the Dashboard.  Is there some browser feature which is used only to populate the data on the Dashboard, and not by any other pages?  Perhaps I need to install some browser add-on, or change some configuration?  I have tried clearing the browser cache, but that made no difference.

There have been a number of reports of adblockers installed in the browser interfering with the unRAID GUI.  If you have one whitelist the unRAID server.

Thanks for the suggestion.

 

I do not, knowingly, have any adblockers installed.  My only browser add-ons are the OpenH264 video codec, Shockwave, and the CouchPotato extension.

 

Added information:

 

What appears to be missing on the 'non-working' system is some of the data which is subject to live update.  Live update of the UPS status is working, but 'live update' information in the Array status and System status is missing.

 

Comparing the page source between the 'working' and 'non-working' systems, the source looks to be identical.

 

I am guessing that the part of the page source which looks like:

<td>core 0 / 1</td><td class='blue' id='cpu0'></td><td class='blue' id='cpu1'></td>

is meant to use the "id='cpu0'" to populate the table with the live data.  It is this which is failing.

Do you perhaps have an antivirus program running? This may also interfere with the GUI display.

 

Nope, no AV package installed.

 

I have just installed Chromium on this machine, and it displays the Dashboard page complete with all information.

 

So, there must be something odd/missing in the FF install on this ArchLinux machine (bearing in mind that FF is okay on Linux Mint).

I'm apparently having the same issue. Chrome on my main Mac exhibits it, while Safari and Firefox do not. On my other Mac, Chrome (which is synced to the same account as the other - so same extensions) does not exhibit the issue.

 

For the browser that exhibits it, if I visit my unRAID server from 'tower' rather than the direct IP, it's resolved.

 

So I *think* it's a cached issue, but can't seem to resolve it by clearing caches within the browser.

Wow, you're correct.  I always 'tower', but have just tried IP number and that works fine.  I had already tried clearing the browser cache so it is definitely a little bit odd.

Try killing cookies. I did it from outside the browser (just deleted from disk), and it worked. I did not try within the browser.

Well done!

 

There were a number of cookies stored for 'Tower'.  One was identifiable as belonging to CouchPotato, several belonging to SqueezeBoxServer, and the rest probably belonging to the emhttp interface.  I deleted them all and the Dashboard display returned to normal.

 

I suspect that the use of cookies in the unRAID gui needs to be reviewed.  If the Dashboard was being disrupted by one of its own cookies, then that should be relatively easy to address.  If the Dashboard was being disrupted by one of the other applications cookies, then care needs to be taken to uniquely identify unRAID's own cookies.

 

I will mark this as 'Solved', but hope that a review of cookies will be carried out.

Well done!

 

There were a number of cookies stored for 'Tower'.  One was identifiable as belonging to CouchPotato, several belonging to SqueezeBoxServer, and the rest probably belonging to the emhttp interface.  I deleted them all and the Dashboard display returned to normal.

 

I suspect that the use of cookies in the unRAID gui needs to be reviewed.  If the Dashboard was being disrupted by one of its own cookies, then that should be relatively easy to address.  If the Dashboard was being disrupted by one of the other applications cookies, then care needs to be taken to uniquely identify unRAID's own cookies.

 

I will mark this as 'Solved', but hope that a review of cookies will be carried out.

Another question though is why this problem doesn't happen to most other users?

Another question though is why this problem doesn't happen to most other users?

That is a good question - for which the developer is best-placed to posit an answer.  Clearly, there was a cookie which was blocking some of the data on the Dashboard from being displayed.  Which app , presumably running on my unRAID server, placed the cookie, I do not know.  If it was placed by the web gui itself, then the path which provoked the situation needs to be identified,  If it was another app, then the web gui should not be reacting to it.

 

The fact that two users have identified the same problem, with different browsers, running on different OS/hardware, suggests that it is something which warrants attention.

 

If the situation recurs, I hope that I have time to remove the cookies one-by-one until I can identify the culprit.

Do you have display of Dockers and VMs enabled on the dashboard?

 

If so, can you disable this when the issue re-occurs, it's a kind of elimination to figure out where the issue is located.

 

Next it would be good to know which cookie is the culprit. I can't find an issue with the regular cookies. Perhaps it is the browser itself which chokes on a particular cookie + content?

Do you have display of Dockers and VMs enabled on the dashboard?

 

Yes, I do.

 

If so, can you disable this when the issue re-occurs, it's a kind of elimination to figure out where the issue is located.

 

If/when - yes, I'll do this.

 

Next it would be good to know which cookie is the culprit. I can't find an issue with the regular cookies. Perhaps it is the browser itself which chokes on a particular cookie + content?

 

Yes, obviously identifying the cookie would be useful - sorry that I didn't have time to delete one-by-one earlier.

 

It could be the browser, but bear in mind that the issue has been experienced in both Chrome/MacOS and FF/ArchLinux.

 

I guess that you're saying that you have no fields on the Dashboard page which could be obviously affected by a cookie?

Do you have display of Dockers and VMs enabled on the dashboard?

 

If so, can you disable this when the issue re-occurs, it's a kind of elimination to figure out where the issue is located.

 

Experienced the issue this morning (Chrome, Mac). Disabled Dockers on the Dashboard (I don't use any VMs currently). No change in issue.

 

Next it would be good to know which cookie is the culprit. I can't find an issue with the regular cookies. Perhaps it is the browser itself which chokes on a particular cookie + content?

 

Manually deleting cookies one by one in Chrome's developer console. Once I deleted the cookie named "share mode" (which was set to "2") and reloaded the page, the graphs on the Dashboard returned to normal.

 

Hope this helps!

Do you have display of Dockers and VMs enabled on the dashboard?

 

If so, can you disable this when the issue re-occurs, it's a kind of elimination to figure out where the issue is located.

 

Experienced the issue this morning (Chrome, Mac). Disabled Dockers on the Dashboard (I don't use any VMs currently). No change in issue.

 

Next it would be good to know which cookie is the culprit. I can't find an issue with the regular cookies. Perhaps it is the browser itself which chokes on a particular cookie + content?

 

Manually deleting cookies one by one in Chrome's developer console. Once I deleted the cookie named "share mode" (which was set to "2") and reloaded the page, the graphs on the Dashboard returned to normal.

 

Hope this helps!

 

It certainly does!

 

The cookie you are referring to is used to select the display of the shares. The value 2 means NFS.

 

I'll see if I can replicate the issue.

 

Question: did you make a change in NFS sharing (use / not use) ?

 

 

Question: did you make a change in NFS sharing (use / not use) ?

 

 

No change in the configuration of NFS shares themselves on unRAID, but I did unmount a few shares from my Mac sometime this morning.

Experienced the issue this morning (Chrome, Mac). Disabled Dockers on the Dashboard (I don't use any VMs currently). No change in issue.

 

Next it would be good to know which cookie is the culprit. I can't find an issue with the regular cookies. Perhaps it is the browser itself which chokes on a particular cookie + content?

 

Manually deleting cookies one by one in Chrome's developer console. Once I deleted the cookie named "share mode" (which was set to "2") and reloaded the page, the graphs on the Dashboard returned to normal.

 

Hope this helps!

 

It certainly does!

 

The cookie you are referring to is used to select the display of the shares. The value 2 means NFS.

 

I'll see if I can replicate the issue.

 

Question: did you make a change in NFS sharing (use / not use) ?

 

I can confirm this!  Simply switching to 'nfs' in the shares list and redisplaying the dashboard page results in missing data.(and the shares list setting has reverted to 'smb').

Thanks all, for your investigations and feedback.

 

I've made a correction for the next release.