noties

You probably want to look at this: https://github.com/alexjustesen/speedtest-tracker/releases/tag/v0.16.0 It looks like your data just got moved to another table.

You are the bomb. That worked! Thank you. It barked on my entry name 'release' number so I just removed it, but after that it worked.

Has anyone gotten KVM to pass a BIOS serial to the guest OS? I realize that there's nothing specific to unraid's implementation of KVM, but I've followed the documentation pertaining to passing sysinfo to the guest here: https://libvirt.org/formatdomain.html#elementsSysinfo It never yields a serial number in the OS. I'm testing with Windows 10 as I have an application that requires the BIOS number to run. I saw this post about adding a serial #, but it seems like treading into Unraid OS modification which I'd like to stay away from if possible. https://github.com/atomspring/KVM-BIOS-SerialNo Here's the beginning of my guest XML: <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>angrychipmunk</name> <uuid>337e27d5-91b2-4108-79cb-07ebc7dbaf94</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>4</vcpu> <sysinfo type='smbios'> <bios> <entry name='vendor'>LENOVO</entry> <entry name='version'>1.24</entry> <entry name='date'>06/21/21</entry> <entry name='release'>.61</entry> </bios> <system> <entry name='manufacturer'>LENOVO</entry> <entry name='product'>Virt-Manager</entry> <entry name='version'>0.9.4</entry> <entry name='serial'>WF610061</entry> <entry name='uuid'>337e27d5-91b2-4108-79cb-07ebc7dbaf94</entry> </system> <baseBoard> <entry name='manufacturer'>LENOVO</entry> <entry name='product'>20BE0061MC</entry> <entry name='version'>0B98401 Pro</entry> <entry name='serial'>W1KS610061616</entry> </baseBoard> <chassis> <entry name='manufacturer'>LENOVO</entry> <entry name='version'>2.12</entry> <entry name='serial'>6665X0X111F2</entry> <entry name='asset'>40000101</entry> <entry name='sku'>Sku1</entry> </chassis> </sysinfo> <os> <type arch='x86_64' machine='pc-i440fx-7.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/337e27d5-91b2-4108-79cb-07ebc7dbaf94_VARS-pure-efi.fd</nvram> </os> <features>

Hmm... My ESXi server accesses a few shares via NFS. I don't believe ESXi supports SMB. I'll give the hard links disable a try.

Ran memtest and it returned errors/failure. I have 4 x 8GB DIMMs so I removed all but one and re-ran memtest. This time it passed OK. I ran on 8GB for a few days with no issues, but at reduced capacity -- i.e. only running plex container and a few others. I have since replaced my RAM with brand new 2 x 8GB ECC DIMMs and turned up the rest of my containers. This morning I woke up to find the following error message and some of my containers unresponsive via network. They showed started, but not accessible. Some worked fine, others did not. I'm wondering if there's an issue with my network interface? I have 3 x NICs in use. eth0 = onboard motherboard ethernet (realtek) - Unraid IP network eth 3 (intel 4 port card) = docker vlan eth 4 (intel 4 port card) = docker vpn vlan Oct 18 23:05:43 teraserver shfs: shfs: ../lib/fuse.c:1451: unlink_node: Assertion `node->nlookup > 1' failed. Oct 18 23:05:47 teraserver kernel: veth25cb69d: renamed from eth0 Oct 18 23:05:51 teraserver kernel: ------------[ cut here ]------------ Oct 18 23:05:51 teraserver kernel: nfsd: non-standard errno: -107 Oct 18 23:05:51 teraserver kernel: WARNING: CPU: 9 PID: 17229 at fs/nfsd/nfsproc.c:853 nfserrno+0x47/0x4f [nfsd] Oct 18 23:05:51 teraserver kernel: Modules linked in: xt_mark nvidia_uvm(PO) veth xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat xt_nat xt_tcpudp iptable_mangle nf_tables vhost_net tun vhost vhost_iotlb tap macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs nfsd lockd grace sunrpc md_mod nvidia_drm(PO) nvidia_modeset(PO) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops nvidia(PO) drm backlight agpgart nct6775 hwmon_vid ip6table_filter ip6_tables iptable_filter ip_tables x_tables tg3 igb i2c_algo_bit sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper rapl mxm_wmi mpt3sas ahci intel_cstate i2c_i801 intel_uncore libahci raid_class input_leds i2c_smbus scsi_transport_sas led_class wmi button i2c_core [last unloaded: tg3] Oct 18 23:05:51 teraserver kernel: CPU: 9 PID: 17229 Comm: nfsd Tainted: P O 5.10.28-Unraid #1 Oct 18 23:05:51 teraserver kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X79 Extreme4-M, BIOS P3.40 03/10/2018 Oct 18 23:05:51 teraserver kernel: RIP: 0010:nfserrno+0x47/0x4f [nfsd] Oct 18 23:05:51 teraserver kernel: Code: ff c0 48 83 f8 22 75 e1 80 3d 1b 2b 01 00 00 41 bc 00 00 00 05 75 15 48 c7 c7 b5 09 29 a0 c6 05 05 2b 01 00 01 e8 a5 1f 42 e1 <0f> 0b 44 89 e0 41 5c c3 48 83 ec 18 31 c9 ba ff 07 00 00 65 48 8b Oct 18 23:05:51 teraserver kernel: RSP: 0018:ffffc900007ebe30 EFLAGS: 00010286 Oct 18 23:05:51 teraserver kernel: RAX: 0000000000000000 RBX: ffff8881449c4800 RCX: 0000000000000027 Oct 18 23:05:51 teraserver kernel: RDX: 00000000ffffdfff RSI: 0000000000000001 RDI: ffff88842fa58920 Oct 18 23:05:51 teraserver kernel: RBP: ffff88816987c000 R08: 0000000000000000 R09: 00000000ffffdfff Oct 18 23:05:51 teraserver kernel: R10: ffffc900007ebc60 R11: ffffc900007ebc58 R12: 0000000005000000 Oct 18 23:05:51 teraserver kernel: R13: ffff8883d5db1000 R14: 0000000000000018 R15: ffff88816987c000 Oct 18 23:05:51 teraserver kernel: FS: 0000000000000000(0000) GS:ffff88842fa40000(0000) knlGS:0000000000000000 Oct 18 23:05:51 teraserver kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 18 23:05:51 teraserver kernel: CR2: 0000151500b2b060 CR3: 000000000200a002 CR4: 00000000001726e0 Oct 18 23:05:51 teraserver kernel: Call Trace: Oct 18 23:05:51 teraserver kernel: nfsd3_proc_getattr+0x82/0xa1 [nfsd] Oct 18 23:05:51 teraserver kernel: nfsd_dispatch+0xb0/0x11e [nfsd] Oct 18 23:05:51 teraserver kernel: svc_process+0x3dd/0x546 [sunrpc] Oct 18 23:05:51 teraserver kernel: ? nfsd_svc+0x27e/0x27e [nfsd] Oct 18 23:05:51 teraserver kernel: nfsd+0xef/0x146 [nfsd] Oct 18 23:05:51 teraserver kernel: ? nfsd_destroy+0x57/0x57 [nfsd] Oct 18 23:05:51 teraserver kernel: kthread+0xe5/0xea Oct 18 23:05:51 teraserver kernel: ? __kthread_bind_mask+0x57/0x57 Oct 18 23:05:51 teraserver kernel: ret_from_fork+0x22/0x30 Oct 18 23:05:51 teraserver kernel: ---[ end trace fc17d4152dee4af7 ]--- teraserver-diagnostics-20211019-0636.zip teraserver-diagnostics-20211019-0636.zip

Not recently or since this started happening. I haven't had any other issues that led me to believe it was hardware related, but I could go ahead and run a memtest and report.

Recently started getting general protection faults like below. It's intermittent, but finally leads to being unable to stop dockers and cleanly shutdown. Some dockers will hang or crash. Thought it was related to my NVIDIA drivers - downgraded to earlier version and still having same issues. Only other thing that's changed recently is updated a few plugins and docker images. Not sure I can decipher the GPF below to pinpoint the issue - any help is appreciated. Oct 11 20:45:38 teraserver kernel: general protection fault, probably for non-canonical address 0x27ff888137e4ec5c: 0000 [#14] SMP PTI Oct 11 20:45:38 teraserver kernel: CPU: 9 PID: 6029 Comm: find Tainted: P D O 5.10.28-Unraid #1 Oct 11 20:45:38 teraserver kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X79 Extreme4-M, BIOS P3.30 04/29/2014 Oct 11 20:45:38 teraserver kernel: RIP: 0010:errseq_sample+0x0/0xe Oct 11 20:45:38 teraserver kernel: Code: 8d 0c d5 00 00 00 00 48 83 ca ff 48 d3 e2 48 f7 d2 48 21 d0 0f 1f 00 48 85 c0 0f 94 c0 0f b6 c0 c3 0f 1f 00 b8 f2 ff ff ff c3 <8b> 07 ba 00 00 00 00 f6 c4 10 0f 44 c2 c3 8b 17 31 c0 39 16 74 1b Oct 11 20:45:38 teraserver kernel: RSP: 0018:ffffc90004ad3cd8 EFLAGS: 00010206 Oct 11 20:45:38 teraserver kernel: RAX: ffff8881cb09c240 RBX: ffff88847e835b00 RCX: 0000000000000064 Oct 11 20:45:38 teraserver kernel: RDX: 0000000000000000 RSI: 0000000500000000 RDI: 27ff888137e4ec5c Oct 11 20:45:38 teraserver kernel: RBP: ffff8881cb0a88b0 R08: ffff8881045a4160 R09: ffff8881cb09c240 Oct 11 20:45:38 teraserver kernel: R10: 0000000000000002 R11: 0000000000000002 R12: ffff88847e835b00 Oct 11 20:45:38 teraserver kernel: R13: 0000000000000000 R14: ffff88847e835b10 R15: 0000000000038900 Oct 11 20:45:38 teraserver kernel: FS: 0000145e5e2de740(0000) GS:ffff88881fa40000(0000) knlGS:0000000000000000 Oct 11 20:45:38 teraserver kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 11 20:45:38 teraserver kernel: CR2: 0000145e5e280000 CR3: 0000000104978003 CR4: 00000000001726e0 Oct 11 20:45:38 teraserver kernel: Call Trace: Oct 11 20:45:38 teraserver kernel: do_dentry_open+0x4f/0x289 Oct 11 20:45:38 teraserver kernel: path_openat+0x85e/0x937 Oct 11 20:45:38 teraserver kernel: ? filename_lookup+0xb8/0xdf Oct 11 20:45:38 teraserver kernel: ? verify_dirent_name+0x1d/0x29 Oct 11 20:45:38 teraserver kernel: do_filp_open+0x4c/0xa9 Oct 11 20:45:38 teraserver kernel: ? _cond_resched+0x1b/0x1e Oct 11 20:45:38 teraserver kernel: ? getname_flags+0x24/0x146 Oct 11 20:45:38 teraserver kernel: ? kmem_cache_alloc+0x108/0x130 Oct 11 20:45:38 teraserver kernel: do_sys_openat2+0x6f/0xec Oct 11 20:45:38 teraserver kernel: do_sys_open+0x35/0x4f Oct 11 20:45:38 teraserver kernel: do_syscall_64+0x5d/0x6a Oct 11 20:45:38 teraserver kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Oct 11 20:45:38 teraserver kernel: RIP: 0033:0x145e5e3e7692 Oct 11 20:45:38 teraserver kernel: Code: 58 f6 c2 40 75 3a 89 d0 45 31 d2 25 00 00 41 00 3d 00 00 41 00 74 29 64 8b 04 25 18 00 00 00 85 c0 75 45 b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 82 00 00 00 48 83 c4 78 c3 0f 1f 44 00 00 Oct 11 20:45:38 teraserver kernel: RSP: 002b:00007ffedaf71a60 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 Oct 11 20:45:38 teraserver kernel: RAX: ffffffffffffffda RBX: 00007ffedaf71bdc RCX: 0000145e5e3e7692 Oct 11 20:45:38 teraserver kernel: RDX: 00000000000b0900 RSI: 00000000004a6fc8 RDI: 0000000000000009 Oct 11 20:45:38 teraserver kernel: RBP: 00000000004a6ec0 R08: 0000000000000000 R09: 0000000000000000 Oct 11 20:45:38 teraserver kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Oct 11 20:45:38 teraserver kernel: R13: 0000000000000004 R14: 0000000000000004 R15: 0000000000449ed0 Oct 11 20:45:38 teraserver kernel: Modules linked in: xt_mark nvidia_uvm(PO) veth macvlan xt_nat nf_conntrack_netlink xt_addrtype br_netfilter xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink vhost_net tun vhost vhost_iotlb tap xfs nfsd lockd grace sunrpc md_mod nvidia_drm(PO) nvidia_modeset(PO) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops nvidia(PO) drm backlight agpgart nct6775 hwmon_vid ip6table_filter ip6_tables iptable_filter ip_tables x_tables tg3 igb i2c_algo_bit x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel mxm_wmi kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd mpt3sas glue_helper rapl intel_cstate intel_uncore raid_class ahci i2c_i801 scsi_transport_sas input_leds wmi libahci led_class i2c_smbus button i2c_core [last unloaded: tg3] Oct 11 20:45:38 teraserver kernel: ---[ end trace cee35a8be90d51cc ]--- Oct 11 20:45:38 teraserver kernel: RIP: 0010:dentry_string_cmp+0x9/0x44 Oct 11 20:45:38 teraserver kernel: Code: 80 b8 00 00 40 00 ba 00 00 50 00 0f 45 c2 eb 05 b8 00 00 30 00 f6 47 0d 08 74 05 0d 00 00 02 00 c3 31 c0 4c 8b 0c 06 83 fa 07 <4c> 8b 04 07 76 11 4d 39 c8 75 2a 48 83 c0 08 83 ea 08 75 e5 31 c0 Oct 11 20:45:38 teraserver kernel: RSP: 0018:ffffc90005d7bc08 EFLAGS: 00010206 Oct 11 20:45:38 teraserver kernel: RAX: 0000000000000000 RBX: ffff8881c9f4f500 RCX: 000000000000000a Oct 11 20:45:38 teraserver kernel: RDX: 000000000000004f RSI: ffff88810101c020 RDI: 31ff8881c97224f0 Oct 11 20:45:38 teraserver kernel: RBP: 0000004fcef95ec2 R08: ffff8881c9f4f500 R09: 64665f3436646d61 Oct 11 20:45:38 teraserver kernel: R10: 0000000000000002 R11: d0d0d0d0d0d0d0d0 R12: ffff8881cb09c0c8 Oct 11 20:45:38 teraserver kernel: R13: ffff8881cb09c0c0 R14: ffffc90005d7bd40 R15: ffff88810101c020 Oct 11 20:45:38 teraserver kernel: FS: 0000145e5e2de740(0000) GS:ffff88881fa40000(0000) knlGS:0000000000000000 Oct 11 20:45:38 teraserver kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 11 20:45:38 teraserver kernel: CR2: 0000145e5e280000 CR3: 0000000104978003 CR4: 00000000001726e0 teraserver-diagnostics-20211011-2039.zip

That's great news. I haven't had time to troubleshoot it more, but will let you and the forum know if I make any progress there.

Take a look a few posts back and you'll see me trying to do the same thing. I have a similar setup (but using br0.30 as interface) My experience was that Telegraf would not work at all unless in host mode. You'll need to make sure you have "Host Access to custom networks" turned is ON in order for Telegraf (in host mode) to talk to your InfluxDB container. The only thing I don't have working still is the running VMs/Dockers icons. I haven't had a chance to troubleshoot these. My setup below: HTH

Heya... Take a look at post #1 and this post: They have pretty much everything you need.

Upon further investigation, it does appear that telegraf isn't able to store data for some keys when in custom network mode. I'm going to do some research and report back if I can figure out a workaround. UPDATE: I moved telegraf back to host mode and all of the stats that seemed to be missing before are back, however I'm seeing errors regarding writing to InfluxDB in my telegraf logs. today at 1:22:52 PM 2021-06-26T20:22:52Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:"teraserver", Flush Interval:10s today at 1:23:21 PM 2021-06-26T20:23:21Z W! [agent] ["outputs.influxdb"] did not complete within its flush interval today at 1:23:21 PM 2021-06-26T20:23:21Z E! [outputs.influxdb] When writing to [http://10.3.3.138:8086]: failed doing req: Post "http://10.3.3.138:8086/write?db=telegraf": context deadline exceeded (Client.Timeout exceeded while awaiting headers) today at 1:23:21 PM 2021-06-26T20:23:21Z E! [agent] Error writing to outputs.influxdb: could not write any address today at 1:23:31 PM 2021-06-26T20:23:31Z W! [agent] ["outputs.influxdb"] did not complete within its flush interval today at 1:23:31 PM 2021-06-26T20:23:31Z E! [outputs.influxdb] When writing to [http://10.3.3.138:8086]: failed doing req: Post "http://10.3.3.138:8086/write?db=telegraf": context deadline exceeded (Client.Timeout exceeded while awaiting headers) today at 1:23:31 PM 2021-06-26T20:23:31Z E! [agent] Error writing to outputs.influxdb: could not write any address today at 1:23:41 PM 2021-06-26T20:23:41Z W! [agent] ["outputs.influxdb"] did not complete within its flush interval today at 1:32:11 PM 2021-06-26T20:32:11Z W! [outputs.influxdb] Metric buffer overflow; 102 metrics have been dropped today at 1:32:22 PM 2021-06-26T20:32:22Z W! [outputs.influxdb] Metric buffer overflow; 8 metrics have been dropped The data is most certainly being written to InfluxDB. I can see the POSTs in the InfluxDB and as mentioned above, I'm seeing the data in Grafana. I'm not sure if this is a data validation issue or cosmetic. I'd prefer not to spam my telegraf logs. Perhaps a telegraf expert might be able to weigh in why I'd be seeing these messages even though the data appears to be written to InfluxDB.

So I finally figured this out. I had the InfluxDB container on my UnRAID bridge network and the Varken container on my custom docker network (br1). For whatever reason, Varken (or InfluxDB) would not successfully write the library_stats tag key to the DB. The moment I moved my InfluxDB to my docker network, library_stats started writing. Unfortunately, this forced me to move everything in my Grafana stack to my docker network -- including telegraf. Everything appears to be working except for VM/docker icons which I think I can do without and may remove those panels. I think this pertains to the docker network not being able to communicate with the UnRAID IP. I did need to make one change to my telegraf.conf that pertained to the APCUPSD. I changed the servers statement to point to my UnRAID IP instead of 127.0.0.1. # # Monitor APC UPSes connected to apcupsd [[inputs.apcupsd]] # # A list of running apcupsd server to connect to. # # If not provided will default to tcp://127.0.0.1:3551 servers = ["tcp://10.1.1.99:3551"]

Good idea. I've been spending time reading about and learning Grafana before asking for help. Just couldn't figure this one out easily. I'm going try doing a clean panel and seeing if that will work. I'll report back.

Masked for privacy. It does seem to be working for other tiles in the dashboard like Stream Overview, Stream Bandwidth, Media Types, Media Qualities, etc. The library tiles are the only thing having an issue. I do see library_stats data getting written to Influx in my Varken logs:

Yeah, I've done that with other tiles in the dashboard, but this one is not giving me any choices so I'm wondering if I have something misconfigured on the Varken, Grafana, or Tautulli side of things. In fact, I don't see library_stats as an available choice. I'm wondering if that's the cause, though I'm not sure where I need to enable that or if it's possible. I don't see anything to enable in Tautulli and I can see all of my libraries there. Relevant varken.ini for tautulli [tautulli-1] url = 10.3.3.110:8181 fallback_ip = x.x.x.x apikey = xxxxxxxxxx ssl = false verify_ssl = false get_activity = true get_activity_run_seconds = 30 get_stats = true get_stats_run_seconds = 3600

Awesome dashboard. THANK YOU! I have everything customized to my server, however struggling with the Plex libraries via Varken. I'm pulling other data from Varken DB, but these I cannot find the correct query for the life of me. I have other Varken data populating completely fine... Example: my Movies database is called Movies... Not sure why this isn't picking up? Suggestions on troubleshooting?

Generic paperless-ng question: I currently have a large number of PDFs that I'm just storing in folders. Example: \Autos \Autos\Car1 \Autos\Car2 \Finance \Finance\Bank1 \Finance\Bank2 \Taxes \Taxes\2020 \Taxes\2019 .... Many of the PDFs are OCR already but some are not. I'm looking for a way to ingest all of my PDF/documents and make them all easier to search and retain some sort of structure as above. Windows search is pathetically slow or cumbersome to search PDFs and since I don't know if all of them are OCR, it can easily miss. Would paperless-ng be a good solution to handle this? Would I create correspondents for each of my "folders" and/or "subfolder names"? How much training will I have to do? And can I just manually drag them to these identifiers? For instance, I normally need to grab all of documents related to a tax year. I don't want to have to go fishing for the documents. Trying to figure out a good workflow before going headlong into a new document management process. Also, it appears that if I drag PDFs into paperless-ng, that it creates a whole new PDF from the original, thus almost doubling the size of my library. Should I just turn off archiving? Will I still be able to search the PDFs? or should I (can I) have paperless-ng OCR the file and overwrite the original if it did not contain OCR text already? Looking for guidance. Cheers.

I ran full memtest with newest version of memtest (9.0) and all memory passed testing. I'm now thinking this is related to my docker networking, user defined networks, and the specific ethernet hardware I have. I think it is related to the folliowing: I have since moved my containers off of the Unraid IP physical port and moved them to another physical port. I have not had crashes or errors in the last 24 hours, but will report back after a longer period of time. I believe this to be my issue.

Yes, ran a memtest on each of the RAM sticks individually. I was having BTRFS issues with my previous RAM and that sparked me to test the memory. I've not seen BTRFS errors since swapping out the RAM and the RAM passed memtest. I changed a few things all at once and this seems to be biting me. I swapped motherboards, RAM, and upgraded to 6.9rc2. I had zero problems with my previous mobo, RAM and 6.8.3.

Following up. I ended up having a hard crash of my Unraid server a couple hours later after that message. This time, I got the following message in syslog when it crashed. Crashed, as in, dropped network connectivity, refused connections to any container, and no input on the physical console. Hoping this is right forum to be posting this. Diagnostics attached. HARD CRASH Feb 19 15:00:02 teraserver rpcbind[3654]: connect from 192.168.4.7 to getport/addr(555555555) Feb 19 15:02:16 teraserver rpcbind[11177]: connect from 192.168.4.7 to getport/addr(555555555) Feb 19 15:07:33 teraserver ool www[22782]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_scrub 'start' '/var/lib/docker' '-r' Feb 19 15:07:33 teraserver kernel: BTRFS info (device loop2): scrub: started on devid 1 Feb 19 15:07:57 teraserver kernel: BTRFS info (device loop2): scrub: finished on devid 1 with status: 0 Feb 19 15:08:05 teraserver kernel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details. Feb 19 15:08:32 teraserver emhttpd: shcmd (235): /usr/local/sbin/mover &> /dev/null & Feb 19 15:13:06 teraserver kernel: general protection fault, probably for non-canonical address 0x315a4c61f4cef4d8: 0000 [#1] SMP PTI Feb 19 15:13:06 teraserver kernel: CPU: 15 PID: 0 Comm: swapper/15 Tainted: P W O 5.10.1-Unraid #1 Feb 19 15:13:06 teraserver kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X79 Extreme4-M, BIOS P3.40 03/10/2018 Feb 19 15:13:06 teraserver kernel: RIP: 0010:nf_conntrack_udp_packet+0x119/0x219 Feb 19 15:13:06 teraserver kernel: Code: 81 48 8b 73 20 49 c7 c0 9b 6d dc 81 b9 11 00 00 00 e8 f0 9f 11 00 83 c8 ff e9 ea 00 00 00 48 8b 85 b8 00 00 00 48 85 c0 74 1b <0f> b6 50 06 84 d2 74 13 48 01 d0 74 0e 48 8b 00 48 85 c0 74 06 48 Feb 19 15:13:06 teraserver kernel: RSP: 0018:ffffc90000494b70 EFLAGS: 00010206 Feb 19 15:13:06 teraserver kernel: RAX: 315a4c61f4cef4d8 RBX: ffffc90000494c68 RCX: 0000000000000011 Feb 19 15:13:06 teraserver kernel: RDX: 0000000000000014 RSI: 0000000000000000 RDI: ffff888596154200 Feb 19 15:13:06 teraserver kernel: RBP: ffff888115eae3c0 R08: ffff88819c1a47d0 R09: ffff888115eae3c0 Feb 19 15:13:06 teraserver kernel: R10: ffffffff8210da40 R11: ffff888115eae3c0 R12: 0000000000000002 Feb 19 15:13:06 teraserver kernel: R13: 00000000000000b0 R14: 0000000000000014 R15: ffff888115eae3c0 Feb 19 15:13:06 teraserver kernel: FS: 0000000000000000(0000) GS:ffff888627bc0000(0000) knlGS:0000000000000000 Feb 19 15:13:06 teraserver kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 19 15:13:06 teraserver kernel: CR2: 000014e0b6b8fbd0 CR3: 000000000200c002 CR4: 00000000001706e0 Feb 19 15:13:06 teraserver kernel: Call Trace: Feb 19 15:13:06 teraserver kernel: <IRQ> Feb 19 15:13:06 teraserver kernel: nf_conntrack_in+0x2bc/0x3b7 Feb 19 15:13:06 teraserver kernel: ? br_handle_frame_finish+0x351/0x351 Feb 19 15:13:06 teraserver kernel: nf_hook_slow+0x39/0x8e Feb 19 15:13:06 teraserver kernel: ? br_nf_forward_finish+0xd0/0xd0 Feb 19 15:13:06 teraserver kernel: NF_HOOK+0xb7/0xf7 Feb 19 15:13:06 teraserver kernel: ? br_nf_forward_finish+0xd0/0xd0 Feb 19 15:13:06 teraserver kernel: br_nf_pre_routing+0x229/0x239 Feb 19 15:13:06 teraserver kernel: ? br_nf_forward_finish+0xd0/0xd0 Feb 19 15:13:06 teraserver kernel: br_handle_frame+0x25e/0x2a6 Feb 19 15:13:06 teraserver kernel: ? br_pass_frame_up+0xda/0xda Feb 19 15:13:06 teraserver kernel: __netif_receive_skb_core+0x335/0x4e7 Feb 19 15:13:06 teraserver kernel: ? inet_gro_receive+0x252/0x264 Feb 19 15:13:06 teraserver kernel: __netif_receive_skb_list_core+0x78/0x104 Feb 19 15:13:06 teraserver kernel: netif_receive_skb_list_internal+0x1bf/0x1f2 Feb 19 15:13:06 teraserver kernel: gro_normal_list+0x1d/0x39 Feb 19 15:13:06 teraserver kernel: napi_complete_done+0x79/0x104 Feb 19 15:13:06 teraserver kernel: tg3_poll_msix+0xb3/0x124 [tg3] Feb 19 15:13:06 teraserver kernel: net_rx_action+0xf4/0x29d Feb 19 15:13:06 teraserver kernel: __do_softirq+0xc4/0x1c2 Feb 19 15:13:06 teraserver kernel: asm_call_irq_on_stack+0x12/0x20 Feb 19 15:13:06 teraserver kernel: </IRQ> Feb 19 15:13:06 teraserver kernel: do_softirq_own_stack+0x2c/0x39 Feb 19 15:13:06 teraserver kernel: __irq_exit_rcu+0x45/0x80 Feb 19 15:13:06 teraserver kernel: common_interrupt+0x119/0x12e Feb 19 15:13:06 teraserver kernel: asm_common_interrupt+0x1e/0x40 Feb 19 15:13:06 teraserver kernel: RIP: 0010:arch_local_irq_enable+0x7/0x8 Feb 19 15:13:06 teraserver kernel: Code: 00 48 83 c4 28 4c 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 9c 58 0f 1f 44 00 00 c3 fa 66 0f 1f 44 00 00 c3 fb 66 0f 1f 44 00 00 <c3> 55 8b af 28 04 00 00 b8 01 00 00 00 45 31 c9 53 45 31 d2 39 c5 Feb 19 15:13:06 teraserver kernel: RSP: 0018:ffffc900000e7ea0 EFLAGS: 00000246 Feb 19 15:13:06 teraserver kernel: RAX: ffff888627be2300 RBX: 0000000000000004 RCX: 000000000000001f Feb 19 15:13:06 teraserver kernel: RDX: 0000000000000000 RSI: 000000002f6898f3 RDI: 0000000000000000 Feb 19 15:13:06 teraserver kernel: RBP: ffffe8fffefc8200 R08: 0000032cd47e275f R09: 0000000000000000 Feb 19 15:13:06 teraserver kernel: R10: 0000000000002bd2 R11: 071c71c71c71c71c R12: 0000032cd47e275f Feb 19 15:13:06 teraserver kernel: R13: ffffffff820c7e80 R14: 0000000000000004 R15: 0000000000000000 Feb 19 15:13:06 teraserver kernel: cpuidle_enter_state+0x101/0x1c4 Feb 19 15:13:06 teraserver kernel: cpuidle_enter+0x25/0x31 Feb 19 15:13:06 teraserver kernel: do_idle+0x1a1/0x20f Feb 19 15:13:06 teraserver kernel: cpu_startup_entry+0x18/0x1a Feb 19 15:13:06 teraserver kernel: secondary_startup_64_no_verify+0xb0/0xbb Feb 19 15:13:06 teraserver kernel: Modules linked in: veth xt_nat xt_CHECKSUM ipt_REJECT ip6table_mangle ip6table_nat iptable_mangle ip6table_filter ip6_tables vhost_net tun vhost vhost_iotlb tap macvlan xt_MASQUERADE iptable_filter iptable_nat nf_nat ip_tables xfs nfsd lockd grace sunrpc md_mod nvidia_drm(PO) nvidia_modeset(PO) drm_kms_helper drm backlight agpgart syscopyarea sysfillrect nvidia_uvm(PO) sysimgblt fb_sys_fops nvidia(PO) nct6775 hwmon_vid r8169 realtek tg3 x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd mxm_wmi cryptd glue_helper rapl i2c_i801 mpt3sas intel_cstate i2c_smbus i2c_core raid_class intel_uncore ahci wmi scsi_transport_sas libahci button [last unloaded: realtek] Feb 19 15:13:06 teraserver kernel: ---[ end trace 53855679afd353bd ]--- Feb 19 15:13:06 teraserver kernel: RIP: 0010:nf_conntrack_udp_packet+0x119/0x219 Feb 19 15:13:06 teraserver kernel: Code: 81 48 8b 73 20 49 c7 c0 9b 6d dc 81 b9 11 00 00 00 e8 f0 9f 11 00 83 c8 ff e9 ea 00 00 00 48 8b 85 b8 00 00 00 48 85 c0 74 1b <0f> b6 50 06 84 d2 74 13 48 01 d0 74 0e 48 8b 00 48 85 c0 74 06 48 Feb 19 15:13:06 teraserver kernel: RSP: 0018:ffffc90000494b70 EFLAGS: 00010206 Feb 19 15:13:06 teraserver kernel: RAX: 315a4c61f4cef4d8 RBX: ffffc90000494c68 RCX: 0000000000000011 Feb 19 15:13:06 teraserver kernel: RDX: 0000000000000014 RSI: 0000000000000000 RDI: ffff888596154200 Feb 19 15:13:06 teraserver kernel: RBP: ffff888115eae3c0 R08: ffff88819c1a47d0 R09: ffff888115eae3c0 Feb 19 15:13:06 teraserver kernel: R10: ffffffff8210da40 R11: ffff888115eae3c0 R12: 0000000000000002 Feb 19 15:13:06 teraserver kernel: R13: 00000000000000b0 R14: 0000000000000014 R15: ffff888115eae3c0 Feb 19 15:13:06 teraserver kernel: FS: 0000000000000000(0000) GS:ffff888627bc0000(0000) knlGS:0000000000000000 teraserver-diagnostics-20210220-0829.zip

Got the following message in syslog on RC2. second time I've seen it and I don't notice anything wrong with my server, but thought I would post to see if someone knows something about it. Looks like something related to the macvlan process maybe? Feb 19 13:23:57 teraserver kernel: ------------[ cut here ]------------ Feb 19 13:23:57 teraserver kernel: WARNING: CPU: 13 PID: 23974 at net/netfilter/nf_conntrack_core.c:1120 __nf_conntrack_confirm+0x99/0x1e1 Feb 19 13:23:57 teraserver kernel: Modules linked in: vhost_net tun vhost vhost_iotlb tap kvm_intel kvm xt_CHECKSUM ipt_REJECT ip6table_mangle ip6table_nat iptable_mangle ip6table_filter ip6_tables md_mod dm_crypt dm_mod dax veth macvlan xt_nat xt_MASQUERADE iptable_filter iptable_nat nf_nat ip_tables xfs nfsd lockd grace sunrpc nvidia_drm(PO) nvidia_modeset(PO) drm_kms_helper drm backlight agpgart syscopyarea nvidia_uvm(PO) sysfillrect sysimgblt fb_sys_fops nvidia(PO) nct6775 hwmon_vid r8169 realtek tg3 x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd mxm_wmi mpt3sas glue_helper rapl i2c_i801 intel_cstate raid_class i2c_smbus intel_uncore i2c_core input_leds ahci led_class scsi_transport_sas wmi libahci button [last unloaded: kvm] Feb 19 13:23:57 teraserver kernel: CPU: 13 PID: 23974 Comm: kworker/13:1 Tainted: P W O 5.10.1-Unraid #1 Feb 19 13:23:57 teraserver kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X79 Extreme4-M, BIOS P3.40 03/10/2018 Feb 19 13:23:57 teraserver kernel: Workqueue: events macvlan_process_broadcast [macvlan] Feb 19 13:23:57 teraserver kernel: RIP: 0010:__nf_conntrack_confirm+0x99/0x1e1 Feb 19 13:23:57 teraserver kernel: Code: e4 e3 ff ff 8b 54 24 14 89 c6 41 89 c4 48 c1 eb 20 89 df 41 89 de e8 54 e1 ff ff 84 c0 75 b8 48 8b 85 80 00 00 00 a8 08 74 18 <0f> 0b 89 df 44 89 e6 31 db e8 89 de ff ff e8 af e0 ff ff e9 1f 01 Feb 19 13:23:57 teraserver kernel: RSP: 0018:ffffc9000043cd38 EFLAGS: 00010202 Feb 19 13:23:57 teraserver kernel: RAX: 0000000000000188 RBX: 0000000000000478 RCX: 000000007f7d0276 Feb 19 13:23:57 teraserver kernel: RDX: 0000000000000000 RSI: 00000000000000f0 RDI: ffffffff82009c00 Feb 19 13:23:57 teraserver kernel: RBP: ffff888271c808c0 R08: 00000000fa10a875 R09: ffff8881a92aeaa0 Feb 19 13:23:57 teraserver kernel: R10: 0000000000000158 R11: ffff888125843200 R12: 00000000000000f0 Feb 19 13:23:57 teraserver kernel: R13: ffffffff8210da40 R14: 0000000000000478 R15: ffff888271c808cc Feb 19 13:23:57 teraserver kernel: FS: 0000000000000000(0000) GS:ffff888627b40000(0000) knlGS:0000000000000000 Feb 19 13:23:57 teraserver kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 19 13:23:57 teraserver kernel: CR2: 00003c2889e6a008 CR3: 000000000200c001 CR4: 00000000001706e0 Feb 19 13:23:57 teraserver kernel: Call Trace: Feb 19 13:23:57 teraserver kernel: <IRQ> Feb 19 13:23:57 teraserver kernel: nf_conntrack_confirm+0x2f/0x36 Feb 19 13:23:57 teraserver kernel: nf_hook_slow+0x39/0x8e Feb 19 13:23:57 teraserver kernel: nf_hook.constprop.0+0xb1/0xd8 Feb 19 13:23:57 teraserver kernel: ? ip_protocol_deliver_rcu+0xfe/0xfe Feb 19 13:23:57 teraserver kernel: ip_local_deliver+0x49/0x75 Feb 19 13:23:57 teraserver kernel: ip_sabotage_in+0x43/0x4d Feb 19 13:23:57 teraserver kernel: nf_hook_slow+0x39/0x8e Feb 19 13:23:57 teraserver kernel: nf_hook.constprop.0+0xb1/0xd8 Feb 19 13:23:57 teraserver kernel: ? l3mdev_l3_rcv.constprop.0+0x50/0x50 Feb 19 13:23:57 teraserver kernel: ip_rcv+0x41/0x61 Feb 19 13:23:57 teraserver kernel: __netif_receive_skb_one_core+0x74/0x95 Feb 19 13:23:57 teraserver kernel: process_backlog+0xa3/0x13b Feb 19 13:23:57 teraserver kernel: net_rx_action+0xf4/0x29d Feb 19 13:23:57 teraserver kernel: __do_softirq+0xc4/0x1c2 Feb 19 13:23:57 teraserver kernel: asm_call_irq_on_stack+0x12/0x20 Feb 19 13:23:57 teraserver kernel: </IRQ> Feb 19 13:23:57 teraserver kernel: do_softirq_own_stack+0x2c/0x39 Feb 19 13:23:57 teraserver kernel: do_softirq+0x3a/0x44 Feb 19 13:23:57 teraserver kernel: netif_rx_ni+0x1c/0x22 Feb 19 13:23:57 teraserver kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Feb 19 13:23:57 teraserver kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Feb 19 13:23:57 teraserver kernel: process_one_work+0x13c/0x1d5 Feb 19 13:23:57 teraserver kernel: worker_thread+0x18b/0x22f Feb 19 13:23:57 teraserver kernel: ? process_scheduled_works+0x27/0x27 Feb 19 13:23:57 teraserver kernel: kthread+0xe5/0xea Feb 19 13:23:57 teraserver kernel: ? kthread_unpark+0x52/0x52 Feb 19 13:23:57 teraserver kernel: ret_from_fork+0x22/0x30 Feb 19 13:23:57 teraserver kernel: ---[ end trace 388b86a70436712d ]---

Woohoo! Finally getting syslog hook messages and it's working. Nov 18 09:22:25 teraserver kernel: mdcmd (34010): spindown 7 Nov 18 09:22:28 teraserver SAS Assist v0.7: spinning down slot 7, device /dev/sdh (/dev/sg7) The green dot doesn't turn gray, but checking the disk status from the console, it's showing spun down. root@teraserver:~# sdparm --command=sense /dev/sdh /dev/sdh: HGST HUH721010AL4200 A21D Additional sense: Standby condition activated by command

Here you go: root@teraserver:/tmp# sdparm --command=sense /dev/sd[a-m] /dev/sda: Kingston DataTraveler 3.0 /dev/sdb: ATA SAMSUNG MZ7GE960 303Q /dev/sdc: ATA SAMSUNG MZ7GE960 5F3Q /dev/sdd: ATA TOSHIBA DT01ACA3 ABB0 /dev/sde: HGST HUH721010AL4200 A21D /dev/sdf: HGST HUH721010AL4200 A21D /dev/sdg: HGST HUH721010AL4200 A21D /dev/sdh: HGST HUH721010AL4200 A21D /dev/sdi: HGST HUH721010AL4200 A21D /dev/sdj: ATA ST3000DM001-1CH1 CC29 /dev/sdk: ATA WDC WD100EMAZ-00 0A83 /dev/sdl: HGST HUH721010AL4200 A21D /dev/sdm: HGST HUH721010AL4200 A21D root@teraserver:/tmp# smartctl -i /dev/sdb smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Samsung based SSDs Device Model: SAMSUNG MZ7GE960HMHP-00003 Serial Number: S1M7NWAG301550 LU WWN Device Id: 5 002538 8700b85c8 Firmware Version: EXT0303Q User Capacity: 960,197,124,096 bytes [960 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Mon Oct 5 15:49:09 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled root@teraserver:/tmp# smartctl -i /dev/sdc smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Samsung based SSDs Device Model: SAMSUNG MZ7GE960HMHP-00003 Serial Number: S1M7NWAG400880 LU WWN Device Id: 5 002538 8700e6b26 Firmware Version: EXT05F3Q User Capacity: 960,197,124,096 bytes [960 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Mon Oct 5 15:50:16 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled root@teraserver:/tmp# smartctl -i /dev/sdd smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Toshiba 3.5" DT01ACA... Desktop HDD Device Model: TOSHIBA DT01ACA300 Serial Number: Y32A1DJGS LU WWN Device Id: 5 000039 ff4d2a87c Firmware Version: MX6OABB0 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 7200 rpm Form Factor: 3.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Mon Oct 5 15:50:29 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled root@teraserver:/tmp# smartctl -i /dev/sde smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721010AL4200 Revision: A21D Compliance: SPC-4 User Capacity: 10,000,831,348,736 bytes [10.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca2512035e4 Serial number: 7PGKR4TG Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Oct 5 15:50:51 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled root@teraserver:/tmp# smartctl -i /dev/sdf smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721010AL4200 Revision: A21D Compliance: SPC-4 User Capacity: 10,000,831,348,736 bytes [10.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca2511b29d0 Serial number: 7PGGY38G Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Oct 5 15:51:03 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled root@teraserver:/tmp# smartctl -i /dev/sdg smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721010AL4200 Revision: A21D Compliance: SPC-4 User Capacity: 10,000,831,348,736 bytes [10.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca2510f09fc Serial number: 7PG88DBS Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Oct 5 15:51:16 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled root@teraserver:/tmp# smartctl -i /dev/sdh smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721010AL4200 Revision: A21D Compliance: SPC-4 User Capacity: 10,000,831,348,736 bytes [10.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca2512068a4 Serial number: 7PGKUJKG Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Oct 5 15:51:29 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled root@teraserver:/tmp# smartctl -i /dev/sdi smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721010AL4200 Revision: A21D Compliance: SPC-4 User Capacity: 10,000,831,348,736 bytes [10.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca251206dec Serial number: 7PGKUWGG Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Oct 5 15:51:43 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled root@teraserver:/tmp# smartctl -i /dev/sdj smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.14 (AF) Device Model: ST3000DM001-1CH166 Serial Number: Z1F346DA LU WWN Device Id: 5 000c50 03ce5a7e0 Firmware Version: CC29 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 7200 rpm Form Factor: 3.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Mon Oct 5 15:51:54 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled root@teraserver:/tmp# smartctl -i /dev/sdk smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: WDC HGST Ultrastar He10 Device Model: WDC WD100EMAZ-00WJTA0 Serial Number: 2YK14YTD LU WWN Device Id: 5 000cca 273eacd81 Firmware Version: 83.H0A83 User Capacity: 10,000,831,348,736 bytes [10.0 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Form Factor: 3.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Mon Oct 5 15:52:05 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled root@teraserver:/tmp# smartctl -i /dev/sdl smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721010AL4200 Revision: A21D Compliance: SPC-4 User Capacity: 10,000,831,348,736 bytes [10.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca26695fd14 Serial number: 7JJNH4DG Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Oct 5 15:52:26 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled root@teraserver:/tmp# smartctl -i /dev/sdm smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721010AL4200 Revision: A21D Compliance: SPC-4 User Capacity: 10,000,831,348,736 bytes [10.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca25120538c Serial number: 7PGKT40G Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Oct 5 15:52:41 2020 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled

I have both a local and remote. I just disabled the remote syslog for good measure and removed and re-installed the plug-in. I'm still getting the same behavior. I force spindown on a drive by clicking the green button light. The temp indicator goes turns to *, but the button stays green. I get no SAS Assist messages in the log. I have a mixture of SAS and SATA HDD in here. Would that cause an issue? How does it know which is which? Also my SMART controller type for my SAS drives all say "Use default" - not sure if that's an issue or would it need to be changed to SCSI.

DM'd you the log file. I have a remote syslog server and scanning the log real quick, thought it may have an issue with that... not sure.