baracas

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?

Yeh, sorry I didn't specify its disk 3. I'm in the process of moving data off of it to other places. Extended smart tests error out. I had heard that read errors weren't necessarily the end of the world. But if I were to put parity disk in the array with a disk getting read errors like that, what would happen during a correcting parity check? I don't exactly know myself. But just seems, with my limited knowledge, unwise to leave a suspect disk in a array for long term. Maybe after zeroing it out or something, it may still have a home as a unassigned device or something. idk. Thanks for responding.

So I set up my unraid server over the last week or 2. Everything went well. Finally got around to running a read check (no parity drive yet) and got 168 errors on one drive. There umc errors I believe, Diagnostic attached, but still. I had funds and "planed" on adding a parity drive this month, but given the status of that disk, I'm guessing the best course of action would be to move some data around so that I can remove that data disk and replace it. And just have to add a parity drive at a later time when funds become available again. Or if there's something else I could do, I'm open to suggestions as what to do. I haven't tried replacing the sata cable yet, but I will. But I'm doubting thats the issue, its an old drive. Thanks. p67-diagnostics-20200706-1515.zip

I'm "somewhat" concerned about this drive. Maybe just being a little to paranoid, Idk. But my questions is : I have about 4 4tb drives in my machine, one being suspect. In the next month I'll will have funds to get another as a parity drive, I'm currently running unprotected array. Should I do use the new drive as parity as I had planed, or is the one in question already too suspect and use the new one the replace it. I would have to use unbalance or something to transfer stuff around but no big deal. And if I do that, then I would either still be left with an unprotected array, or use this possibly suspect drive as a parity drive. Which I don't really want to do, but I'll only have $ for 1 additional drive in the short term. Or just do as I planed and a the new drive as parity and hope for the best one the questionable on? The suspect drive is the first one wd4000fdyz. Edit: added diagnostics. p67-diagnostics-20200630-1333.zip