5 hours ago, Jamaica1985 said:

Everything works as expected however, both the main page and the dashboard show no hardware information whatsoever. I see no disks, no CPU stats, no Fan stats, no array however everything else is working just fine. Not sure where to start to troubleshoot this...

 

Is this from you accessing via a reverse proxy (enable websocket support if so).  Otherwise, try closing all open browser tabs etc to the server

18 hours ago, Jamaica1985 said:

Everything works as expected however, both the main page and the dashboard show no hardware information whatsoever. I see no disks, no CPU stats, no Fan stats, no array however everything else is working just fine. Not sure where to start to troubleshoot this...

 

I actually have experienced this in version 6.10.2. It fixed itself by refreshing and/or closing the window and re-opening it, restarting the server. The issue hasn't come back. I'm still on version 6.10.2. I will update later. Updated to 6.10.3 without issues.

Edited June 17, 20224 yr by JustOverride

The Mellanox Connectx-2 no longer connects since the upgrade to this version, on a GEN8

I can no longer access the Unraid web interface

In ILO the machine has started up properly

Edited June 17, 20224 yr by Daleksek
More informations

14 minutes ago, Daleksek said:

The Mellanox Connectx-2 no longer connects since the upgrade to this version, on a GEN8

I can no longer access the Unraid web interface

Please start a new thread in the general support forum and don't forget to include the diagnostics.

On 6/15/2022 at 2:45 AM, JonathanM said:

If you need it, you can re-enable. If you don't need it, don't bother.

I don't even know what it does but having disabled it with no adverse effect I guess I don't need it!

1 minute ago, Hitcher said:

I don't even know what it does but having disabled it with no adverse effect I guess I don't need it!

That was the point. It's used to pass hardware directly into a VM, instead of emulating the resource in software. Most common use is a video card, where you have a monitor directly connected to the card in the server, and when you start the VM, it shows on the attached monitor.

 

If you don't need it, no point in enabling it.

Is there  reason that array disks won't spin down after this upgrade.

 

After upgrade (smooth, no problems) to 6.10.3 all but one of my array disks are staying spinning with no file access.

 

If i spin the array down manually (using the little down arrow button under the disk listing) they almost immediately spin up in response to a smart request. This is copy and past from the live log:

 

Jun 17 15:03:43 shortie emhttpd: spinning down /dev/sdj
Jun 17 15:03:43 shortie emhttpd: spinning down /dev/sdk
Jun 17 15:03:44 shortie emhttpd: spinning down /dev/sdh
Jun 17 15:03:45 shortie emhttpd: spinning down /dev/sdi
Jun 17 15:03:46 shortie emhttpd: spinning down /dev/sdf
Jun 17 15:03:46 shortie emhttpd: spinning down /dev/sdg
Jun 17 15:03:47 shortie emhttpd: spinning down /dev/sdd
Jun 17 15:03:49 shortie emhttpd: read SMART /dev/sdj
Jun 17 15:03:49 shortie emhttpd: read SMART /dev/sdg
Jun 17 15:03:49 shortie emhttpd: read SMART /dev/sdf
Jun 17 15:03:58 shortie emhttpd: read SMART /dev/sdk
Jun 17 15:04:08 shortie emhttpd: read SMART /dev/sdh
Jun 17 15:04:08 shortie emhttpd: read SMART /dev/sdd
Jun 17 15:04:08 shortie emhttpd: read SMART /dev/sdi

 

With 6.10.2 the array was spun down as expected. 

 

I have Dynamix cache directories installed and one disk is reporting as over temperature (server in marginally cooled location and its hot, ironically, because the array is spun up). 

 

Thanks 

Eric

6 minutes ago, something fishy said:

I have Dynamix cache directories installed

Try removing / disabling that and see if the behaviour changes.

3 minutes ago, something fishy said:

I have Dynamix cache directories installed and one disk is reporting as over temperature (server in marginally cooled location and its hot, ironically, because the array is spun up). 

 

I seem to recall that this can cause problems if you cache too many files.  (Apparently, the available RAM to store the names fills up and it discards the earliest names for the later ones.  Then it 'figures out' that it is missing those file names so it re-reads those and deletes some more files.  You can see where this becomes a dog chasing its tail...)

44 minutes ago, JonathanM said:

Try removing / disabling that and see if the behaviour changes.

Removing Dynamix cache directories and rebooting appears to have sorted it. Smart requests in the log no longer spin up the disk and unused disks spin down on schedule.

 

Thanks, this is mostly static, infrequently accessed data so spindown is important on heat and power grounds.

 

Cheers

 

Eric

16 minutes ago, something fishy said:

this is mostly static, infrequently accessed data

The plugin lets you exclude specified shares.

2 minutes ago, something fishy said:

Removing Dynamix cache directories and rebooting appears to have sorted it. Smart requests in the log no longer spin up the disk and unused disks spin down on schedule.

 

Thanks, this is mostly static, infrequently accessed data so spindown is important on heat and power grounds.

 

Cheers

 

Eric

IF  you find the delay in getting a file listing is an annoyance for certain shares, you can setup Cache Directories so that it only caches those shares.   For example, I only have it only cache my Media share which has about 3000 files in it.  (IF I were to cache all the shares in the server, we would be looking at ~100,000 files!)

1 hour ago, something fishy said:

Is there  reason that array disks won't spin down after this upgrade.

 

Mine spin down fine. I know that doesn't help you, but know that it does work.

2 hours ago, trurl said:

The plugin lets you exclude specified shares.

I appreciate that. Thank you. I've removed for the moment. 

 

It was working as designed on 6.10.2 (no impact on disk sleep that I could see or any other negative side effects) and with the same settings carried over appeared not to work as designed on 6.10.3. 

 

 

Are you sure appdata, domains, system shares don't have files on the array?

Is it possible to bypass the webgui password?  Like you can do with nzbget

 

http://192.168.2.5:6789/nzbget:tegbzn6789/

 

 

Typing the password each time is annoying...

4 minutes ago, nightanole said:

Is it possible to bypass the webgui password?

No, unless you find a bug that allows it, in which case it needs to get fixed ASAP.

 

5 minutes ago, nightanole said:

Typing the password each time is annoying...

Use the password manager built in to your browser, or a good third party one like Bitwarden (Vaultwarden available as a self hosted solution).

6 minutes ago, JonathanM said:

No, unless you find a bug that allows it, in which case it needs to get fixed ASAP.

 

Use the password manager built in to your browser, or a good third party one like Bitwarden (Vaultwarden available as a self hosted solution).

It was more of an issue for "non routine maintenance".  Trying to use a tablet one handed in the basement, etc.  

 

Yea the main just last last pass running.  But GG trying to type the lastpass password, and then getting to the unraid gui etc, on a tablet, when you are already pissed off and in the dark because a sata cable is being crabby

Small warning,

 

I've lost access to my server. I detected it when DNS queries were no more solve by my DNS server container. I've tried connecting to GUI, but it freezed then were no more reachable (ping answer however).

 

I initiated a reboot through IPMI but after 3H, the diagnostic file wasn't generated yet, due to graceful stop unsuccesful. So I proceded to a forced shutdown. 

 

This happened onto my SuperMicro server, linked on the 2 host's ethernet port by 802.3ad. No troubleshoot when I checked this link on the Mikrotik router...

 

Next time it occurs, i'll try to wait enough for the server to generate the diagnostic files to be posted on the General Support channel, but 3h is not normal and already long enough..

14 hours ago, trurl said:

Are you sure appdata, domains, system shares don't have files on the array?

This is for me? 

Yes I'm sure. Appdata is cache only and my sageTV recording directory is on a pool drive not on the array. These shares were excluded from cache directories and were working as expected in 6.10.3: asleep when not used.

 

With the plug in removed, expected behaviour has returned to all disks. The only disks spun up are those that have current file activity.

 

For eg, at time of writing I have a scheduled windows disk image running so one array drive and parity are spun up, plus cache (an SSD). The remaining 6 array drives are asleep. SageTV has just started recording so its dedicated pool drive spun up around 3 minutes ago.

 

Thanks

 

On 6/16/2022 at 2:35 PM, Jamaica1985 said:

Everything works as expected however, both the main page and the dashboard show no hardware information whatsoever. I see no disks, no CPU stats, no Fan stats, no array however everything else is working just fine. Not sure where to start to troubleshoot this...

Did you solve this because mine is the same?

 

EDIT: A reboot fixed it.

Edited June 18, 20224 yr by Hitcher

4 hours ago, something fishy said:

Appdata is cache only

Just having it set that way doesn't mean it has no files on the array. It only means all new files would go to cache.

I didn't notice this until today, but has the syntax to "newperms" script changed after  unRaid 6.8.3 ?

 

I used to always use "newperms ." to change the permissions on the current directory I'm in. Doing so on 6.10.3 results in the permissions of /usr/local/emhttp/plugins/dynamix/scripts/ changing instead. This breaks things.

 

 

 

 

Edited June 18, 20224 yr by BRiT

29 minutes ago, trurl said:

Just having it set that way doesn't mean it has no files on the array. It only means all new files would go to cache.

It doesn't have files on the array according to the "compute" button in the shares tab and verified with Midnight Commander.

 

I used to have some orphan appdata files and I forced them off under 6.10.2.

 

As I've said, all was normal with the cache directories plugin operating in 6.10.2 and all seems normal in 6.10.3 without the plugin. 

 

Thanks

 

 

4 hours ago, BRiT said:

I used to always use "newperms ." to change the permissions on the current directory I'm in. Doing so on 6.10.3 results in the permissions of /usr/local/emhttp/plugins/dynamix/scripts/ changing instead. This breaks things.

 

newperms only operates on user content in /mnt, it doesn't touch internals.