-
(SOLVED) Unraid Crashing
Yes, the syslogs were pulled from the flash drive as soon as I force rebooted. Your advice on the BIOS settings seemed to have worked, thank you so much! It's been up for a few hours now, but yesterday and earlier today it had gotten to the point of crashing every 10 minutes, even sitting idle with VMs and Docker containers off. In case anyone else finds this: I also figured out my memory was going bad. I ran memtest and identified which stick was bad. My server would still crash after removing it until I changed the BIOS settings linked by JorgeB. Not sure if that made my problem worse or was related at all, but figured I'd mention it. Thanks again! I have no idea what I would've done without this advice.
-
(SOLVED) Unraid Crashing
Thanks, I'll try that. I shut off most of them now and will see if it still crashes, then stop/start one at a time from here. My Docker image recently corrupted and I had to rebuild my containers. I wonder if it was caused by whichever docker container is still causing me issues. The list of my containers is below: ActualServer apprise-api authentik authentik-worker dumbassets Glance GluetunVPN HomeAssistant_inabox immich kopia LubeLogger nextcloud-aio-mastercontainer Nginx-Proxy-Manager-JC21 NPMplus paperless-ngx Plex-Media-Server Postgres12.5 PostgreSQL_Immich Redis-authentik Redis-paperless redis-vouchervault syncthing UptimeKuma VoucherVault
-
-
(SOLVED) Unraid Crashing
Hello, my Unraid 7.1.4 server has been crashing at least once a day, sometimes multiple times a day. I am unable to access the login page, it becomes unresponsive to pings or SSH, and all services stop working until I force shutdown. I figured out how to save the syslog to the flash drive. I think Docker is causing the issue, but I'm not sure how to fix it. Please let me know if I should change something. Specifically, I see lines like this in the syslog: Oct 25 16:58:30 Tower kernel: docker0: port 18(veth7a065bb) entered blocking state Oct 25 16:58:30 Tower kernel: docker0: port 18(veth7a065bb) entered forwarding state Oct 25 16:59:12 Tower kernel: TCP: request_sock_TCP: Possible SYN flooding on port 10.96.0.31:42678. Sending cookies. syslog-previous syslog
-
(Solved) Disk suddenly unmountable
This solved my issue, thank you!
-
(Solved) Disk suddenly unmountable
Hello, my data disk is suddenly showing as Unmountable: Unsupported or no file system. I have tried rebooting and replacing the sata cable with no luck. I ran xfs_repair with the -n option and the result is below. Can someone please provide guidance on how I can repair the issue without losing data? I have important files backed up, but would rather save this if possible. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... invalid start block 0 in record 0 of bno btree block 0/1 invalid start block 0 in record 255 of cnt btree block 0/2068651 agf_freeblks 108515719, counted 108515715 in ag 0 agi unlinked bucket 12 is 6212940 in ag 0 (inode=6212940) sb_icount 529856, counted 530112 sb_ifree 318, counted 95 sb_fdblocks 534365589, counted 533859465 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 bad nblocks 18446744073709551577 for inode 4701659101, would reset to 0 data fork in ino 4769315924 claims free block 596172975 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 1 - agno = 2 bad nblocks 18446744073709551577 for inode 4701659101, would reset to 0 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 6212940, would move to lost+found Phase 7 - verify link counts... would have reset inode 6212940 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. tower-diagnostics-20241124-2205.zip
ElTecnico
Members
-
Joined
-
Last visited