testdasi

For one second I read that as "users (wives)" 😅 On serious note, I wonder if it's HBA-related (maybe new kernel doesn't like the driver?) since the other user reporting strange issues also appears to use a HBA too. This seems to happen every time there's a major kernel upgrade. Defo need Diagnostics.

Let's flip the question back. Why would you want to update to the RC version if it sounds like you cannot afford to have issue? The general consensus is to always run stable on production servers and RC on test servers (or if you have a specific issue for which a fix is not yet available in stable).

As always, Tools -> Diagnostics -> attach zip file (preferably to your first post).

Did it happen on 6.8.0-rc1? If it didn't then I don't think it's related to 6.8-rc - you might have an actual problem at hand and not just a bug.

Typo? shouldn't it be 32400?

Hmmm could it be network issue on your end? On my gigabit, it took seconds.

@SpaceInvaderOne: When I connect remotely to the Mac VM, I noticed that there are 2 cursors (tried both NoMachine and VNC). The one underneath is offset very slightly to the upper left. When I move the mouse around, the underneath cursor would trail the the other one to the next location. I have tested that the one above is the actual cursor so I'm not sure what's up with the underneath one. Do you know how to fix that?

A few tips from my own experience: Use VNC Viewer to connect to the VM for setup. It will save you a lot of gripes over timeout and such with Clover. There are 2 install steps. The first after diskutil and then it would restart, you have to make sure to boot into your newly formatted disk to complete the install. Otherwise Clover will boot back into the install media. You can edit the xml to change things such as number of CPU cores. But I have found 6 cores to cause boot issues. 4 cores is ok.

Your USB stick could be shorting the port. Corrupted data on the USB stick typically doesn't cause reboot (more likely that it just won't boot at all) because the OS is loaded into RAM. I would recommend using a different port.

I shall disagree with this. For Unraid typical uses, you will hardly (if ever) see any performance diff between the 970 Evo and 970 Pro. Both Evo and Pro have 5-year warranty Just for a bit more than the 970 Pro 512GB, you can get the Evo 1TB. That is equivalent of having 30% more cells to wear out! Even comparing similar size, the relatively lower endurance of the Evo can be mitigated with good practice. SSD rarely fails catastrophically like HDD. It's not like you writes 300TB to your 970 Evo and it suddenly stops working (unlike Intel SSD). It will continue to work until all the cells die, which is a long time.

There is no need to complicate it with a VM - remember Unraid is based on Linux to begin with. Also with regards to using rclone with Unraid, follow this topic:

Don't know if it's a bug or not but all my Shares switched to High Water mode instead of my usual Most Free. No big deal - I just switch stuff back manually but I reckon it might be a major annoyance for some.

Yeah, no other choice but to redo CPU pinning. That's why SpaceInvaderOne topology video is extremely useful.

Hmm, if it's just 6-week old then it's not likely to be the problem. While you are close to 550W, it shouldn't be something affected by a 6-week-old PSU aging. I don't think it's CPU overheating that's the issue. 60 degrees is nothing with Xeon. Your CPU is also rather low power and should be within the limit of the Noctua L9i. I have done some light overclock with the L9i so while it's not D15 level, it should not be overheating your Xeon. Perhaps you can start with setting up Syslog Server (Settings -> Syslog Server) to save log locally and/or mirror to flash so you can see what happens at the point of reboot. Your current diagnostics looks to be after the reboot which doesn't have the syslog before (which would be more useful).

I use google gdrive as my offsite backup. Rclone does the encryption on-the-fly so I don't have to trust Google (not that I don't trust Google).

You are very confused. A share is access in the following way (I'm assuming you are using windows and thus SMB) via the network from \\servername\sharename directly within Unraid by pointing things to User share: /mnt/user/sharename Disk share: /mnt/disk# Unassigned devices: /mnt/disks/sharename (in your case: /mnt/disks/USB_BACKUP) You don't "access" a share by going to SHARES->DISK SHARES. You "see" that USB_BACKUP is a share by the blue button under the "Share" column on UD. That to signify it is NOT on the array, unlike the SHARES tab, which specifies shares on the array.

Wrong place to look for the share. Press the + sign on the screenshot I quoted above (look to the right of "sdb"), it will expand to show you the mountpoint, which is the same as the "share". It is normally rather cryptic but you can rename it to something more useful (click on it and type in new name and then enter)

Could it possibly be a problem with the PSU? Your config is pretty damn close to the 550W of the PSU so if it has not aged graciously, it could very well be under-powering under heavy load. That is particularly relevant with HDD which can cause power surge spinning up/down etc.

Nope. 👍

That can sometimes happen due to driver corruption so I suggest also reinstall the Nvidia driver too.

If you are looking for a easy click-and-forget thing then there isn't one unfortunately. The rclone commands are pretty simple and easy to understand though + rclone wiki is very helpful. You just have to be comfortable with command line (and set up bash scripts).

Hey easy with the attitude buddy! I thought you were trying to adapt another docker to work with Unraid so just wanted to let you know that it is already on CA. Now assuming you are using the CA docker (and not from somewhere else), all you need to do is: Mariadb docker for a sql db phpmyadmin docker to create the Firefly db and user Enter the information you set up from (1) and (2) into the docker template That's it. No special skill required.

You are not describing your issue very clearly. What do you mean by server was up and running but array was not? Like you login to the server and find your array suddenly in stopped state instead? If that's the case, that usually means your server rebooted itself when you weren't watching. The only thing in your log that stands out is this section: Oct 8 15:52:35 Tower apcupsd[5692]: UPS Self Test switch to battery. Oct 8 15:52:44 Tower apcupsd[5692]: UPS Self Test completed: Battery OK Oct 8 19:10:39 Tower kernel: mdcmd (57): spindown 1 Oct 8 19:10:40 Tower kernel: mdcmd (58): spindown 2 Oct 8 19:10:40 Tower kernel: mdcmd (59): spindown 3 Oct 8 19:10:41 Tower kernel: mdcmd (60): spindown 4 Oct 8 19:10:41 Tower kernel: mdcmd (61): spindown 5 Oct 8 19:21:01 Tower kernel: microcode: microcode updated early to revision 0xb4, date = 2019-04-01 Oct 8 19:21:01 Tower kernel: Linux version 4.19.56-Unraid (root@Develop67) (gcc version 8.3.0 (GCC)) #1 SMP Tue Jun 25 10:19:34 PDT 2019 Oct 8 19:21:01 Tower kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot So on Oct 08, At 15:52: there was a UPS test At 19:10: spindown commands were issued for your disks At 19:21: your server rebooted That suggests hardware failure to me. Considering you had overheating issue in the past, any number of devices could have been damaged leading to instability. There is not much you can do other than troubleshoot each device. I would suggest starting from the PSU / UPS.

Go back on the previous page for the script from nuhll.

In general terms, yes. In specific terms, it depends on what GPU and what docker.