Jump to content

weirdcrap

Members
  • Content Count

    223
  • Joined

  • Last visited

Community Reputation

3 Neutral

About weirdcrap

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ah so Android 10 then, not AndroidTV. See if the my Files app lets you specify you want to connect to the public share as a guest. The "Files" app on my Android 11 phone doesn't appear to support looking at my local network so I can't really test your specific scenario out. Let me know if you have trouble connecting with Kodi, I can try to help with it though I mostly use it strictly for the Plex add-on so I can watch offline when the internet goes down (Plex app on the Shield breaks without internet).
  2. Nope, I got two notifications from UnRAID, one about the read errors and a second about the 2 pending sectors. I went to check the SMART stats and saw the discrepancy, canceled the check and shut down the server to swap the disk with another. The diag file posted above is from before I shut down the server and after the alerts were generated. I'll let the parity check finish and order a replacement disk. I missed my warranty window by about 6 months =(
  3. To be clear is this actually an AndroidTV box like the shield TV or is it an "Android box for TVs" like the ones you can find all over Amazon? I ask because some of these actually run AndroidTV while others just run Android and can look and act differently. The "My Files" app is not a part of AndroidTV that I'm aware of so I imagine you are using a set top box with Android installed. On my 2019 Shield TV I was able to use Kodi's file manager to access my UnRAID shares with credentials by passing the credentials as part of the SMB path call: Requiring credentials for public shares is unfortunately rather common when dealing with SMB shares in my experience. It is not an UnRAID issue specifically, certain OSes and apps seem to be able to handle it, others can't. I use File Commander on my shield to side load apps from my UnRAID public share and it works fine (the guest box is required, it doesn't like blank credentials):
  4. UnRAID v6.8.3 void-diagnostics-20200915-0707.zip My monthly parity check on my backup server has produced read errors on disk 1 for the last two months... The first time it happened there was no report of pending re-allocated sectors and the drive passed both a short and long smart self test so I wrote it off as a fluke and went on with my life. This morning it happened again within minutes of the parity check starting, this time with UnRAID claiming there are 2 pending sectors: However when I go to look at the drive stats in the context menu SMART doesn't report any pending or reallocated sectors?? I plan on moving the drive to a different slot and see if the error follows the disk or stays with the slot. Anyone ever seen UnRAID misreport pending sectors like that before? Is SMART just slow on the uptake? EDIT: Swapped disk with another slot, rerunning nocorrect check now. EDIT2: It appears to be following the disk, different slot, same disk with read errors. No reports of reallocated sectors this time by unraid, just read errors. Sep 15 07:25:06 VOID kernel: mdcmd (57): check nocorrect Sep 15 07:25:06 VOID kernel: md: recovery thread: check P ... Sep 15 07:25:24 VOID emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Sep 15 07:26:20 VOID emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Sep 15 07:28:31 VOID ntpd[1859]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Sep 15 07:28:52 VOID kernel: mpt2sas_cm1: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) Sep 15 07:28:52 VOID kernel: mpt2sas_cm1: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) Sep 15 07:28:52 VOID kernel: mpt2sas_cm1: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) Sep 15 07:28:52 VOID kernel: mpt2sas_cm1: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) Sep 15 07:28:52 VOID kernel: mpt2sas_cm1: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) Sep 15 07:28:52 VOID kernel: mpt2sas_cm1: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) Sep 15 07:28:52 VOID kernel: sd 10:0:0:0: [sdp] tag#3130 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Sep 15 07:28:52 VOID kernel: sd 10:0:0:0: [sdp] tag#3130 Sense Key : 0x3 [current] Sep 15 07:28:52 VOID kernel: sd 10:0:0:0: [sdp] tag#3130 ASC=0x11 ASCQ=0x0 Sep 15 07:28:52 VOID kernel: sd 10:0:0:0: [sdp] tag#3130 CDB: opcode=0x88 88 00 00 00 00 00 01 ba 94 b0 00 00 04 00 00 00 Sep 15 07:28:52 VOID kernel: print_req_error: critical medium error, dev sdp, sector 29005968 Sep 15 07:28:52 VOID kernel: md: disk1 read error, sector=29005904 Sep 15 07:28:52 VOID kernel: md: disk1 read error, sector=29005912 Sep 15 07:28:52 VOID kernel: md: disk1 read error, sector=29005920 Sep 15 07:28:52 VOID kernel: md: disk1 read error, sector=29005928 Sep 15 07:29:16 VOID kernel: sd 10:0:0:0: attempting task abort! scmd(00000000ee3221de) Sep 15 07:29:16 VOID kernel: sd 10:0:0:0: [sdp] tag#3104 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Sep 15 07:29:16 VOID kernel: scsi target10:0:0: handle(0x0009), sas_address(0x4433221104000000), phy(4) Sep 15 07:29:16 VOID kernel: scsi target10:0:0: enclosure logical id(0x5c81f660e69c9f00), slot(7) Sep 15 07:29:17 VOID kernel: sd 10:0:0:0: task abort: SUCCESS scmd(00000000ee3221de) Sep 15 07:29:17 VOID kernel: sd 10:0:0:0: Power-on or device reset occurred Sep 15 07:29:22 VOID kernel: sd 10:0:0:0: Power-on or device reset occurred Sep 15 07:29:34 VOID kernel: mpt2sas_cm1: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) Sep 15 07:29:34 VOID kernel: mpt2sas_cm1: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) Sep 15 07:29:34 VOID kernel: sd 10:0:0:0: [sdp] tag#3105 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Sep 15 07:29:34 VOID kernel: sd 10:0:0:0: [sdp] tag#3105 Sense Key : 0x3 [current] Sep 15 07:29:34 VOID kernel: sd 10:0:0:0: [sdp] tag#3105 ASC=0x11 ASCQ=0x0 Sep 15 07:29:34 VOID kernel: sd 10:0:0:0: [sdp] tag#3105 CDB: opcode=0x88 88 00 00 00 00 00 01 ba c8 b0 00 00 04 00 00 00 Sep 15 07:29:34 VOID kernel: print_req_error: critical medium error, dev sdp, sector 29019160 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019096 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019104 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019112 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019120 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019128 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019136 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019144 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019152 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019160 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019168 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019176 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019184 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019192 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019200 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019208 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019216 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019224 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019232 Sep 15 07:29:34 VOID kernel: md: disk1 read error, sector=29019240 Sep 15 07:29:39 VOID rc.diskinfo[12312]: SIGHUP received, forcing refresh of disks info. Sep 15 07:30:57 VOID emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog EDIT: "solved" per say. I know the drive is dying though I do find the ghost re-allocated sectors reported strange. I have a new one on order.
  5. Just came here to see why the update broke the container and what the deal was with the spinning logo. Also not a fan of the animated logo. Thanks for the quick fix.
  6. Is anyone else noticing that the plex docker is starting to get killed for Out of Memory errors during Plex's server maintenance window? This morning alone Plex has been OOM reaped dozens of times, sometimes as often as every minute!! https://pastebin.com/8BcJnQ5J This is happening across two different severs with different memory amounts and client loads (both use LSIO Plex docker). The errors begin within minutes of the maintenance window beginning and never appear after the maintenance window has closed. I do have hard RAM limits set in the docker's config, however they have never approached or hit this limit before in normal operation so I'm hesitant to increase the limit (they are in place to prevent runaway RAM consumption by dockers). NODEFlix has an 8GB RAM limit set for the PMS docker NOTYOFLIX has a 6GB RAM limit set for the PMS docker I haven't changed anything about either servers Plex settings or docker configurations recently. The only thing I can think of is Plex's new "Detect Intro" feature runs as a scheduled task so I have disabled it and will monitor to see if the errors return with that setting off. However I don't recall seeing this issue when that feature was introduced, this problem just appeared a few days ago... Attached are both server diagnostic zips. node-diagnostics-20200705-0545.zipvoid-diagnostics-20200705-0545.zip I've posted about my issues over on the Plex forums since this thread is to massive for anything to be seen or addressed. https://forums.plex.tv/t/server-maintenance-leads-to-excessive-resource-utilization/611012/
  7. For me it is somewhat different. it is 100% reproducible with Chrome (currently version # 83.0.4103.116 (64-bit)) on Windows 10 v1909, the tunnel goes down and stays down. I just tried with Chrome on my Android (Pixel 3A XL w/ Android 10) over LTE and it also brought down the tunnel and did not restart it. The first set of stop/start is me on Windows 10 adding a test peer then logging in locally and re-enabling the tunnel. The second set was me logging in via my android and removing said peer, which also brought down the tunnel. Connected directly to the web interface via the LAN (not a VPN) I can make changes to the tunnel settings in Chrome on Windows 10 and the tunnel rolls without issue. The tunnel only stops and stays down when I'm managing Wireguard over a Wireguard connection. EDIT: Also happens in latest Firefox on Windows. EDIT2: I tried to manage wireguard over wireguard again this time using RDP Windows to Windows machine that I then use to access the unraid webui. Management over the RDP connection tunneled through WireGuard successfully brought the tunnel down and back up. So my problem seems to be any direct attempt to manage the wireguard server over a wireguard connection results in the tunnel going down and staying down. If I connect to another machine on the LAN over wireguard and use that machine to manage the wireguard server then it seems to go down and come back up gracefully.
  8. Is Wireguard supposed to just stop the tunnel and leave it stopped when adding a new peer or making any changes at all really? I setup wireguard remote access to LAN for my phone and PC no problem super easy as advertised. I'm connected over wireguard managing unraid and I go to add a peer, hit apply and the unraid webui stops working because the tunnel has been stopped: Jun 25 09:41:05 Node wireguard: Tunnel WireGuard-wg0 stopped Jun 25 09:43:20 Node webGUI: Successful login user root from xxx.xxx.xxx.xxx Jun 25 09:43:24 Node wireguard: Tunnel WireGuard-wg0 started Thankfully I have other remote access methods to this server so I was able to go in and restart the tunnel but I don't see how this could be by design...shouldn't it be able to gracefully roll the connection? I'll make a new thread if this is unexpected behavior where troubleshooting can be done. EDIT: just got kicked again just trying to change the connection type for a peer that isn't even in use currently. It just stopped the tunnel and left it off... EDIT2: it sounds like depending on how peers are added active session interruption could be avoided: https://manpages.debian.org/unstable/wireguard-tools/wg.8.en.html#COMMANDS:~:text=syncconf EDIT3: I am just so utterly lost on how to make my main server talk to my backup server directly over wireguard. I currently have SSH and rsync running a monthly backup of my data, I would like to stop leaving SSH open to the net but I can't get server to server or remote access to server to work to save my life. I followed your "rough instructions" of setup server to server on one and import on the other but now i have a second tunnel I don't really want. Do I have to have a second tunnel for this to work? Can I not just add the server as a peer to my existing tunnel with my phone and home PC? I got server to server working, still not sure if a second port forward and tunnel was required or not but at least the Chinese will stop spamming my logs with SSH brute force attempts (Key based auth only so it is more aesthetic than a real security concern).
  9. Yeah, I ran a second scrub after deleting the corrupted file and it reports no further errors: UUID: cc9f1614-fc5d-406a-8ee7-58a5651dc9ae Scrub started: Thu May 21 07:58:40 2020 Status: finished Duration: 0:02:48 Total to scrub: 75.17GiB Rate: 458.17MiB/s Error summary: no errors found Thanks for reminding me about not being able to repair without a pool, i forgot that was the case.
  10. Ok cool so I don't necessarily need to do a scrub repair? Neat I'll just delete the file then. Thanks for the reassurance 😃
  11. Unraid v6.8.3 void-diagnostics-20200521-0651.zip <--- diagnostics before any troubleshooting. I'm receiving the following error from my cache drive, it is always the same inode #: BTRFS warning (device sdg1): csum failed root 5 ino 156381873 off 143360 csum 0xf58f6015 expected csum 0xf58f6055 mirror 1 I ran a find on the inode # and it is an Emby poster: find /mnt/cache -inum 156381873 /mnt/cache/appdata/EmbyServer/data/collections/Toy Story Collection [boxset]/poster.jpg I just finished a scrub: May 21 07:08:25 VOID ool www[20615]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_scrub 'start' '/mnt/cache' '-r' May 21 07:10:32 VOID kernel: BTRFS warning (device sdg1): checksum error at logical 1627265449984 on dev /dev/sdg1, physical 57454903296, root 5, inode 156381873, offset 143360, length 4096, links 1 (path: appdata/EmbyServer/data/collections/Toy Story Collection [boxset]/poster.jpg) May 21 07:10:32 VOID kernel: BTRFS error (device sdg1): bdev /dev/sdg1 errs: wr 0, rd 0, flush 0, corrupt 2, gen 0 UUID: cc9f1614-fc5d-406a-8ee7-58a5651dc9ae Scrub started: Thu May 21 07:08:25 2020 Status: finished Duration: 0:03:08 Total to scrub: 75.15GiB Rate: 409.40MiB/s Error summary: csum=1 Corrected: 0 Uncorrectable: 0 Unverified: 0 Should I attempt to repair the corrupted block with BTRFS Scrub? Or should I just delete the affected file and let it be regenerated? I plan on running a memtest later to ensure it isn't bad RAM, though i think if it was bad RAM i would have more than just one bad file after this error going on for over a week. I appear to have at least one pending allocated sector a reserve block used according to SMART for the SSD: void-smart-20200521-0711.zip I wanted to check and see how much data I have written to this cache drive so I found a calculator, this seems wildly out of bounds for a 3 1/2 year old SSD, there is no way I have written 300TB through this drive. BTW, why aren't warnings like this picked up by FCP (Fix Common Problems)? It would be nice to have BTRFS errors reported (a notification generated) for those with cache devices.
  12. Just as anecdotal evidence, I have a bunch of Seagate NAS drives like yours (ST6000VN0041. ST4000VN000. ST2000VN000) on an H200 in IT mode and they all report write caching as enabled without me having to enable anything. As Johnnie said this may be an issue with the firmware on those particular drives as it doesn't affect all of us. root@VOID:/home/root# hdparm -W /dev/sdr /dev/sdr: write-caching = 1 (on) root@VOID:/home/root# hdparm -W /dev/sdi /dev/sdi: write-caching = 1 (on) root@VOID:/home/root# hdparm -W /dev/sdk /dev/sdk: write-caching = 1 (on) root@VOID:/home/root# hdparm -W /dev/sds /dev/sds: write-caching = 1 (on)
  13. Thanks for your help as usual johnnie. After a snafu with a DOA replacement disk I bought a SECOND drive and got it precleared and installed. Did not expect WD to want me to pay shipping on a failed drive under warranty, but thems the breaks. They gave me an RMA so I should be getting a "new" 6tb disk for my trouble.
  14. went the extra mile and had him unplug the server, hold the power button for 30 seconds to discharge all the components, and then plug it back in and powered it up. Still no change, unraid is failing to identify the disk. Good news is it is under warranty for another month and a half from WD, so I can hopefully get a free replacement drive! Never tried to RMA a drive to WD before, do I need to keep and show syslogs of the drive having issues? If they just check SMART the drive may still pass, it was passing until unraid stopped being able to detect it.
  15. Ok, turbo write disabled. I saw it was still changing the write method so I'm glad I asked. By power cycle you mean power it off, unplug it, let it sit for a bit, then power it back up? I'll have to wait for someone to be physically present where the server is to try that. It is looking more and more like this disk is just dead...