itimpi

If you get a similar problem again then often following the procedure documented here seems to fix the issue.

Just tested in a macOS VM. When I selected the diagnostics option in Unraid it downloaded a single zip file. I then opened up 'Downloads' and I could see it there as a single file (although it looked a bit like a folder from the icon). I could then drag/drop this onto a forum message to attach it. What you must NOT do is try and open up that zip file

The combination of macvlan and bridging on eth0 is known to be highly likely to cause the system to crash. If you need to use bridging then you should set the docker networking to use ipvlan instead.

Perhaps you should post a screenshot of Settings->SMB? I thought the values that are set there would be visible in the diagnostics but if they are I could not see them.

As long as you have a valid licence file you can put it into the 'config' folder on a new USB stick and you will be taken through the licence transfer process automatically.

Not if the system really freezes/crashes. It has to be at least working at a basic level for ssh to continue working.

There is definitely a way to do this as we regularly have MacOS users posting the single diagnostics zip file. I might try to bring up a macOS VM to see if I can get the more detailed steps.

Looks like you have a docker container continually crashing which is spamming the logs making it difficult to see what might be going on. You should be able to tell which one this might be by looking at the uptime on the Docker tab.

The diagnostics should be a single zip file. The wall of files you have posted look like the individual files that are the contents of the diagnostics zip file - please post the single zip file as it is much easier to work with.

The syslog is full of resets on the drive that is ata8 which explains the predicted time. These are normally caused by cabling issues (power or SATA) or power issues. Cannot see the first occurrence to see if it helps

the problem is that what looks like the mirrored syslog shows the system being shutdown for a reboot - not the server crashing.

The following will work: Stop array unassign parity drives start array to commit change and make Unraid 'forget' current parity assignments. stop array assign parity drives start array to commit changes and rebuild parity drives. Another (but slightly riskier) option would be: Stop array Use Tools->New Config with the option to keep all current assignments Return to Main tab and check Parity is Valid checkbox Start array - despite warning this parity will not be built as you ticked the checkbox. This is obviously much faster but if parity is NOT valid then you will not be able to rebuild a future failed drive until you have run a parity check with the option to write corrections to parity ticked.

If you want to continue using macvlan then you need to make sure bridging is disabled on eth0.

Not sure why you are talking about buying a new licence?

have you attempted any recovery action so far? I would normally have expected the missing drives to show as being emulated which is not happening. have you tried to see if either of the ‘nor installed’ drives can be mounted (using read-only mode) in Unassigned Devices? It is not infrequent for drives to be disabled by Unraid due to a write failure without the drive having actually failed. You have a lot of drives so perhaps you can provide the serial numbers of the not installed drives (the last 4 characters would be enough) so we can see what (if anything) they are showing in the SMART reports.

Your screenshot on;y shows 2 drives with issues? You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog. in terms of the 2 drives that are showing as “not installed” what actually happened? They should not normally get into that state without some action taken on your part. Do you still have the disks that should be there intact?

You basically want to make settings to limit the number of folders/files to be scanned. If the number is too large the the Linux level will not be able to keep all directory entries in RAM so it is continually re-reading them causing the symptoms you saw.

There is no ‘right’ answer to this as it depends on exactly how you have things set up, but based on you comment it is likely you only want the ‘data’ folder included.

I think defaulting to off is correct. Normally when one uses that option you are going to make a change to the drive assignments that will invalidate parity. If it was set on by default users would not change it and automatically assume their parity (despite them making a dtive change) was valid and only finding out later after a drive failure it was not so data recovery is impossible.

The purpose is to avoid disks in the array being spun up unnecessarily. However you do need to use the included Folders setting to limit to relevant folders to avoid excessive scanning.

The find command running regularly is frequently caused by the cache_dirs plugin. If using that plugin you want to try and limit the folders it scans.

Looks like you have problems with disk6: Mar 6 20:20:09 Tower kernel: ata10.00: failed command: READ FPDMA QUEUED Mar 6 20:20:09 Tower kernel: ata10.00: cmd 60/40:78:c8:88:85/05:00:25:03:00/40 tag 15 ncq dma 688128 in Mar 6 20:20:09 Tower kernel: res 40/00:78:c8:88:85/00:00:25:03:00/40 Emask 0x10 (ATA bus error) Mar 6 20:20:09 Tower kernel: ata10.00: status: { DRDY } Mar 6 20:20:09 Tower kernel: ata10: hard resetting link Mar 6 20:20:09 Tower kernel: ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Mar 6 20:20:09 Tower kernel: ata10.00: configured for UDMA/33 Mar 6 20:20:09 Tower kernel: sd 10:0:0:0: [sdg] tag#9 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=2s Mar 6 20:20:09 Tower kernel: sd 10:0:0:0: [sdg] tag#9 Sense Key : 0x5 [current] Mar 6 20:20:09 Tower kernel: sd 10:0:0:0: [sdg] tag#9 ASC=0x21 ASCQ=0x4 Mar 6 20:20:09 Tower kernel: sd 10:0:0:0: [sdg] tag#9 CDB: opcode=0x88 88 00 00 00 00 03 25 85 68 c8 00 00 05 40 00 00 Mar 6 20:20:09 Tower kernel: I/O error, dev sdg, sector 13514401992 op 0x0:(READ) flags 0x0 phys_seg 168 prio class 2 Mar 6 20:20:09 Tower kernel: md: disk6 read error, sector=13514401928 Mar 6 20:20:09 Tower kernel: md: disk6 read error, sector=13514401936 Mar 6 20:20:09 Tower kernel: md: disk6 read error, sector=13514401944 Mar 6 20:20:09 Tower kernel: md: disk6 read error, sector=13514401952 This looks like a cabling and/or power problem. No obvious issues showing in the SMART reports.

We would need new diagnostics taken while the parity check was finished and with them taken while the system is still exhibiting the symptom?

Is that using its name or its IP address?

Only disks currently actively involved in the parity check will keep spun up