JorgeB

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=755621

Can't see the disk error, syslog is spammed with Nginx errors and was not logging anymore: Apr 15 17:28:22 CaptainMarvel nginx: 2020/04/15 17:28:22 [crit] 10664#10664: ngx_slab_alloc() failed: no memory Apr 15 17:28:22 CaptainMarvel nginx: 2020/04/15 17:28:22 [error] 10664#10664: shpool alloc failed Apr 15 17:28:22 CaptainMarvel nginx: 2020/04/15 17:28:22 [error] 10664#10664: nchan: Out of shared memory while allocating message of size 6156. Increase nchan_max_reserved_memory. Apr 15 17:28:22 CaptainMarvel nginx: 2020/04/15 17:28:22 [error] 10664#10664: *139405 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Apr 15 17:28:22 CaptainMarvel nginx: 2020/04/15 17:28:22 [error] 10664#10664: MEMSTORE:00: can't create shared message for channel /disks Apr 15 17:28:23 CaptainMarvel nginx: 2020/04/15 17:28:23 [crit] 10664#10664: ngx_slab_alloc() failed: no memory Apr 15 17:28:23 CaptainMarvel nginx: 2020/04/15 17:28:23 [error] 10664#10664: shpool alloc failed Apr 15 17:28:23 CaptainMarvel nginx: 2020/04/15 17:28:23 [error] 10664#10664: nchan: Out of shared memory while allocating message of size 6156. Increase nchan_max_reserved_memory. Apr 15 17:28:23 CaptainMarvel nginx: 2020/04/15 17:28:23 [error] 10664#10664: *139411 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Apr 15 17:28:23 CaptainMarvel nginx: 2020/04/15 17:28:23 [error] 10664#10664: MEMSTORE:00: can't create shared message for channel /disks

Yes, GUI can only run SMART tests on ATA drives, you can still run them manually: smartctl -t short /dev/sdX smartctl -t long /dev/sdX

See if it's the same issue as this one:

Preclear or any other disk test before deploying new drives is always a good idea.

Many of the error sectors are the same, which suggests that on one pass they can be found bad and the next one found good and changed back, my prime suspect would be the Sil3132 controller, since some of these are known to corrupt data when both ports are used simultaneously, so first thing would be to replace it with a Asmedia controller (if you don't plan on needing more than those 2 extra ports).

Onboard SATA controller troubles, this is rather common with Ryzen boards, there are some reports that the new kernel on v6.9-beta1 helps.

Nothing obvious in the log, try rebooting in safe mode.

Possibly, also WD SMR disks don't make any strange sounds.

If it's an EFRX yes, if/when they release a WD40EFAX with 256MB cache it will likely be SMR.

Note the the 4TB model is not SMR, at least the current model WD40EFRX.

That's known for a few months: https://forums.unraid.net/topic/82873-wb-my-book-6tb-smr/?do=findComment&comment=768681

No idea.

Yes, and even that it's not a garantee, since many are just a rebrand of the same Chinese stuff.

They should, either one.

There's an option on UD to change a filesystem UUID, but tha's not the problem, and there's no option to change how a device is detected.

It should be fine to start the array, cache should appear as unmountable, but to be safer just unassign the cache devices before starting.

That is exacly the problem, both enclosures use identical identifiers for the disks, only one will work.

Stop the VM service from auto starting, you can do that by editing domain.cfg on the flash drive and changing SERVICE="enable" to "disable", then reboot, I believe individual VM auto-start won't kick in after starting the service manually.

First thing to do is to update the HBA firmware: Apr 14 07:20:15 CaptainMarvel kernel: mpt2sas_cm0: LSISAS2008: FWVersion(20.00.04.00) All p20 firmware releases except latest (20.00.07.00) have known issues.

Any folder created under /mnt/cache is a share and it will appear as a user share under /mnt/user, and it was always like that, it won't appear under /mnt/user0 since that excludes any cache shares.

Only issue I see is a USB device (mounted as /mnt/disks/USB_TOURO) disconnecting without being unmounted first, generating a lot of errors: Apr 14 19:56:24 Tower kernel: usb 2-6: USB disconnect, device number 6 Apr 14 19:56:24 Tower kernel: sd 2:0:0:0: [sdb] Synchronizing SCSI cache Apr 14 19:56:24 Tower kernel: sd 2:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Apr 14 19:56:24 Tower rc.diskinfo[8529]: SIGHUP received, forcing refresh of disks info. Apr 14 19:56:38 Tower emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/startScript.sh /tmp/user.scripts/tmpScripts/rsync_backup_to_TOURO/script Apr 14 19:56:38 Tower root: ### script" ### started Apr 14 19:56:38 Tower kernel: Buffer I/O error on dev sdb1, logical block 36, async page read Apr 14 19:56:38 Tower ntfs-3g[9176]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Apr 14 19:56:38 Tower ntfs-3g[9176]: Failed to read index block: Input/output error Apr 14 19:56:38 Tower ntfs-3g[9176]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Apr 14 19:56:38 Tower ntfs-3g[9176]: Failed to read vcn 0x0: Input/output error Apr 14 19:56:38 Tower ntfs-3g[9176]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error

Stupid large stats numbers usually mean a dropped device, and it's what happened here: Apr 13 18:22:15 Tower kernel: usb 3-3: USB disconnect, device number 3 Apr 13 18:22:15 Tower kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache Apr 13 18:22:15 Tower kernel: sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Apr 13 18:22:15 Tower rc.diskinfo[8170]: SIGHUP received, forcing refresh of disks info. Apr 13 18:22:15 Tower kernel: FAT-fs (sda1): Directory bread(block 30624) failed Apr 13 18:22:15 Tower kernel: FAT-fs (sda1): Directory bread(block 30625) failed Apr 13 18:22:15 Tower kernel: FAT-fs (sda1): Directory bread(block 30626) failed Flash dropped, make sure you're using a USB 2.0 port and/or or try a different port.

You can always go back to a smaller parity. The safer way is to replace one at a time.

There's a Nvidia related crash probably from an auto-starting VM: Apr 14 22:00:30 Database kernel: NVRM: Attempting to remove minor device 0 with non-zero usage count! Apr 14 22:00:30 Database kernel: ------------[ cut here ]------------ Apr 14 22:00:30 Database kernel: WARNING: CPU: 13 PID: 11969 at /tmp/SBo/NVIDIA-Linux-x86_64-440.59/kernel/nvidia/nv-pci.c:577 nv_pci_remove+0xe9/0x2fc [nvidia] See if don't auto starting the VM (or the VM service) makes a difference, then edit that XML.