baracas

That was in the back of my mind. Not seeing anything wrong with drive. Thanks for taking a look, much appreciated.

Hello folks. Happy Halloween. If anyone gets bored I was wanting to get an opinion on a recent read error on my parity drive. I have had small issues in the past with a hdd controller sticking/freezing once ever few months or so. If i remember i think the marvel controller. But its never kicked a drive out of the array before and always resolved itself quickly with some kind of controller reset without manual intervention. Guess I'll run a preclear or something on it and go from there. Smart comes back fine but that doesn't really mean much i don't think. p67-diagnostics-20251030-1418.zip syslog.txt This might be an example of where it looks like the controller resets for a couple of weeks ago but not sure. It doesn't seem quite the same as the errors that kicked the parity drive out of the array: Oct 10 00:25:34 p67 kernel: ata7.00: exception Emask 0x10 SAct 0xc0 SErr 0x400000 action 0x6 frozen Oct 10 00:25:34 p67 kernel: ata7.00: irq_stat 0x08000000, interface fatal error Oct 10 00:25:34 p67 kernel: ata7: SError: { Handshk } Oct 10 00:25:34 p67 kernel: ata7.00: failed command: WRITE FPDMA QUEUED Oct 10 00:25:34 p67 kernel: ata7.00: cmd 61/40:30:f0:7c:2f/05:00:aa:01:00/40 tag 6 ncq dma 688128 out Oct 10 00:25:34 p67 kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Oct 10 00:25:34 p67 kernel: ata7.00: status: { DRDY } Oct 10 00:25:34 p67 kernel: ata7.00: failed command: WRITE FPDMA QUEUED Oct 10 00:25:34 p67 kernel: ata7.00: cmd 61/40:38:30:82:2f/05:00:aa:01:00/40 tag 7 ncq dma 688128 out Oct 10 00:25:34 p67 kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Oct 10 00:25:34 p67 kernel: ata7.00: status: { DRDY } Oct 10 00:25:34 p67 kernel: ata7: hard resetting link Oct 10 00:25:35 p67 kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Oct 10 00:25:35 p67 kernel: ata7.00: configured for UDMA/133 Oct 10 00:25:35 p67 kernel: ata7: EH complete Probably should have posted in support channel. Sorry

Indeed that is it i think. For some reason i was envisioning something worse. FSCK0000.REC FSCK0001.REC made a backup right after that happened. will get a new flash and transfer after i look up the procedure and stuff Thanks, much appriciated.

All that stuff was easy enough to put back in no big there, but I think some hardware event might have caused it. When i rebooted, couldn't log in to wegui or ssh. Webui have reverted to standard port from a custom, and ssh, ntp, time zones, ip addresses dns, and various other mostly non-critical things were either disabled or reverted to what looked like an out of box config. Nothing that can't be changed back that way it was so no major loss. I wonder if its the flash drive, no errors that i can see. I was also having issues with the nvidia 1060 i had in it. I think that card was going bad. Pulled it any out anyway. Idk, that box is older then crap and has had unraid on it for a very long time. But if u get bored and feel like looking at logs holler if u see something im missing. syslog-192.168.7.17.log tower-diagnostics-20240504-0923.zip

Seems my cache drive doesn't want to unmount. ..ever. It might be something docker related or something else idk. I replaced all but 1 of the sata cables, and thats probably the one i didn't. Took 30 min on this shutdown. Killed all the processes but idk. Ive seen a few shutdown issues in the forums thats sound similar. p67-diagnostics-20230710-1912.zip syslog.txt

Thanks thats what i thought, iv'e replaced most of the sata cables but whenever i reboot it, which typically a week or so, this happens right as its rebooting: Jul 7 01:16:32 p67 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT3._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) Jul 7 01:16:32 p67 kernel: ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT3._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529) Jul 7 01:16:32 p67 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) Jul 7 01:16:32 p67 kernel: ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT4._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529) Jul 7 01:16:32 p67 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT5._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) Jul 7 01:16:32 p67 kernel: ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT5._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529) Jul 7 01:16:32 p67 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) Jul 7 01:16:32 p67 kernel: ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT1._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529) So then Unraid registers a unclean shutdown and wants to run parity check. Until i figure it out, I might not bother running parity, or maybe just not reboot it as often p67-diagnostics-20230707-0127.zip

My parity drive dropped off the array. After i noticed it gathered logs and diags and shutdown they system, then watched it boot up on a live monitor. The shutdown was very slow as if something was hung. After bootup getting a message that the parity disk is disabled. My instict was to just run a party sinc after reboot but I decided not to till I attempted to glean some information as to what happened. Its been long time since I've had to troubleshoot this box (unraid has just run without incident for years its seem) so i'm a little rusty. If I'm not misstaken, I think i've seens errors like ACPI BIOS Error (bug): Could not resolve symbol before. Thought they were likely loose sata cables or something, but never knocked a drive out of the array before. Just looking for opinion, worst case im out a parity drive, but i don't want to make things worse by trying to rebuild parity when i shoudn't have to i don't think. idk. So if anyone's board on this holiday morning..... p67-diagnostics-20230704-0425.zip syslog.txt WDC_WD40EZRZ-22GXCB0_WD-WCC7K1JKSDT4-20230704-0425 parity (sdb) - DISK_DSBL.txt

same here

I replaced a hdd with an ssd for my cache driver recently and everything is gone to heck since. Today execution errors on fresh dockers with a new rebuild docker.img. Get stuff like this in docker logs level=error msg="Handler for POST /v1.37/containers/6e4ee040ad10/start returned error: error while creating mount source path '/mnt/user/appdata/plex': mkdir /mnt/user/appdata/plex: no space left on device" There plently of space available thats not true.... I though it might be something with shares but i can't find it. VM'd had issues too, rebuilt the libvirt a few times and work be ok for a while? Seeing a lot of stuff in the syslogs that where never there before as well. At this point I might just wipe the appdata, domains, and system shares, reformat the cache drive entirely and start again. I only use the cache drive for a small handleful of dockers and vms, not as a staging point for data going to array. I did or did not do something when i replaced the drive this time, but i don't know what. I've replace several over the years never had a problem. Must be and old cfg somewhere like on the flash causing all this but i can't find it. p67-diagnostics-20211020-1110.zip syslog-192.168.5.17.log syslog-192.168.5.172.log syslog.txt EDIT: I appears there were conflicting mounts points and the user/appdata share was reporting it was full to unraid. Deleted the share and readded it. If that doesn't work i guess i could trying mounting as a share /mnt/cache/appdata which is prob better anyway.

This is actually worse then i thought, I disabled docker and vms though it was a docker issue but not sure now. I may end up going without a cache drive for a while to see if thats it.

Oct 19 14:55:29 P67 root: Stopping docker_load Oct 19 14:55:29 P67 emhttpd: shcmd (1711): /etc/rc.d/rc.docker stop Oct 19 14:55:29 P67 root: stopping dockerd ... Oct 19 14:55:30 P67 root: waiting for docker to die ... Oct 19 14:55:31 P67 emhttpd: shcmd (1712): umount /var/lib/docker Oct 19 14:55:31 P67 kernel: XFS (loop2): Unmounting Filesystem Oct 19 14:56:16 P67 ool www[21401]: /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker_rm Oct 19 14:57:35 P67 ool www[21402]: /usr/local/emhttp/plugins/dynamix/scripts/emcmd 'cmdStatus=Apply' Oct 19 14:57:35 P67 emhttpd: Starting services... Oct 19 14:57:35 P67 emhttpd: shcmd (1716): /etc/rc.d/rc.samba restart Oct 19 14:57:35 P67 winbindd[21554]: [2021/10/19 14:57:35.607597, 0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler) Oct 19 14:57:35 P67 winbindd[21274]: [2021/10/19 14:57:35.607595, 0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler) Oct 19 14:57:35 P67 winbindd[21554]: Got sig[15] terminate (is_parent=0) Oct 19 14:57:35 P67 winbindd[21274]: Got sig[15] terminate (is_parent=1) Oct 19 14:57:35 P67 wsdd[21271]: udp_send: Failed to send udp packet with Network is unreachable Oct 19 14:57:35 P67 wsdd[21271]: Failed to send bye with Network is unreachable Oct 19 14:57:37 P67 root: Starting Samba: /usr/sbin/smbd -D Oct 19 14:57:37 P67 root: /usr/sbin/wsdd Oct 19 14:57:37 P67 smbd[21975]: [2021/10/19 14:57:37.767594, 0] ../../lib/util/become_daemon.c:135(daemon_ready) Oct 19 14:57:37 P67 smbd[21975]: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections Oct 19 14:57:37 P67 root: /usr/sbin/winbindd -D Oct 19 14:57:37 P67 winbindd[21988]: [2021/10/19 14:57:37.797484, 0] ../../source3/winbindd/winbindd_cache.c:3203(initialize_winbindd_cache) Oct 19 14:57:37 P67 winbindd[21988]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 Oct 19 14:57:37 P67 winbindd[21988]: [2021/10/19 14:57:37.797864, 0] ../../lib/util/become_daemon.c:135(daemon_ready) Oct 19 14:57:37 P67 winbindd[21988]: daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections and a bunch of this: Oct 19 14:53:44 P67 shfs: share cache full Oct 19 14:53:49 P67 shfs: share cache full Oct 19 14:53:54 P67 shfs: share cache full Oct 19 14:53:59 P67 shfs: share cache full Oct 19 14:54:04 P67 shfs: share cache full Oct 19 14:54:09 P67 shfs: share cache full Oct 19 14:54:14 P67 shfs: share cache full I can't find the problem, everthing wen 't well replacing cache drive done it 1/2 a dozen times? p67-diagnostics-20211019-1414.zip syslog-192.168.5.17.log

I was going to set this up, but for a few older family members. But unless I'm missing something, non of these "linked" plex requests systems can be integrated into a normal users "requesters" plex app ui in the form of channel, plugin or anthing can it? For example: Plex>Movies>TV>Photos>Live TV>Ombi all there accessable from within the standard plexapp?