Kreavan

Members
  • Posts

    22
  • Joined

  • Last visited

Kreavan's Achievements

Newbie

Newbie (1/14)

3

Reputation

  1. I've had this docker running flawless for 5 months. I haven't changed anything, but now it is giving the following error: Raising maximum file descriptor to 65535 failed. This may cause problems with many clients. (errno=1) Raising nice-ceiling to 35 failed. (errno=1) Not sure what this is, or how to fix it.
  2. Since I didn't really have anything on that drive needing to be recovered, I wiped the partion, re-formatted, and it's back up and running again. Still unsure what happened, but all good now. Thanks for the help folks!
  3. I went in and disabled "Passthrough" in order to re-enable the option to "Mount." When I tried, it immediately fails. Checked the log and this is what is showing.
  4. Not sure what happened, but all of a sudden my share is only showing 1mb in size. Yet, the drive in unassigned devices is showing 4tb. Uninstalling/reinstalling the plugin did nothing. Tried restoring Appdata from a previous backup (No change either). I've been using the drive as a location for downloads and transcodes. Ran a SMART test and everything passed. This is what is showing currently: File System Check results: when I navigate to the share in VNC, it is showing 1mb in size and I can go into the folder(s). However, I can no longer create anything in there. It is acting like the share is corrupt, but not sure how I can recreate it.
  5. Ok, so I'm on day 3 of zero crashes. Looks like my issue has been fixed. Summary below of the changes that appear to have led me to this stable result. - Moved Unraid USB to 2.0 slot. - Flashed BIOS to latest version (1.30) - Disabled all power management features - No overclocking at all (Everything default or Auto) - Changed BIOS setting "Power Supply Idle Control" to "Typical Current Idle" - Uninstalled GPU Statistics plugin - Added "rcu_nocbs=0-31" to the kernel - Disabled Bonding and Bridging in Network Settings - Changed BIOS setting "Global C State" to "Disabled"
  6. Results of my Windows 10 test. It loaded up fine. I launched Ryzen Master and all the temps are normal. Also ran CPU-Z, Prime95, and Cinebench. Stress test the machine and nothing crashed. One thing to note, I did find out that "Global C-state" in the BIOS was still set to "Auto" when I thought I had disabled it. It is now turned off for sure. So, I'll find out tomorrow if another hard lock occurs overnight. Keeping my fingers crossed.
  7. I appreciate that I'm not the only one. I think what my next step will be is to run Windows 10 off a USB and run Ryzen Master. Maybe that'll give me some more info.
  8. My server hard crashed again last night. This seems to be the trend of it hard crashing overnight when I'm asleep. It runs fine all day. I'm running out of ideas of what could be causing this.
  9. Experienced another hard lock last night while I was asleep. This morning, I did find the Global C State option in the BIOS and have changed it from "Auto" to "Disabled". Hoping this fixes the instability. Keep you posted.
  10. Attached are the screenshots of my BIOS settings. Had to break them into separate zip files as I couldn't upload as a single large zip. 4.zip 3.zip 2.zip 1.zip
  11. The server hard locked sometime last night. The syslog doesn't show any new entries from the last time I checked it. So, I'm a bit lost now. Guess it is something in the BIOS maybe. Any thoughts on what I could check/change there to stabilize my build? I'll try to photos of my current BIOS settings and post them after my shift.
  12. I'm still experiencing random issues with the network connectivity as mentioned in my last post. Based on what I'm seeing in the Syslog, I'm thinking it might have something to do with the Binhex-DelugeVPN docker as I'm finding references of my VPN IP in some of the log lines before it happens. So, I've shut down that docker and will see if that stabilizes things.
  13. I did this very same thing yesterday. I fixed it by booting into GUI mode. Once there, brought up the web interface. Go to Network Settings and on the "Bridging members of br0", add the unchecked. Reboot and it should work.
  14. So, the server did not lock up overnight like it has previously. However, earlier today I did lose connectivity to the web GUI and seemed network activity ceased completely on the server. I checked the Syslog and seems docker0 had some issues. Apr 16 10:28:05 Atlantis kernel: docker0: port 1(veth67de24f) entered disabled state Apr 16 10:28:05 Atlantis kernel: vethd439256: renamed from eth0 Apr 16 10:28:06 Atlantis avahi-daemon[6289]: Interface veth67de24f.IPv6 no longer relevant for mDNS. Apr 16 10:28:06 Atlantis avahi-daemon[6289]: Leaving mDNS multicast group on interface veth67de24f.IPv6 with address fe80::ec65:dbff:fe4a:32e2. Apr 16 10:28:06 Atlantis kernel: docker0: port 1(veth67de24f) entered disabled state Apr 16 10:28:06 Atlantis kernel: device veth67de24f left promiscuous mode Apr 16 10:28:06 Atlantis kernel: docker0: port 1(veth67de24f) entered disabled state Apr 16 10:28:06 Atlantis avahi-daemon[6289]: Withdrawing address record for fe80::ec65:dbff:fe4a:32e2 on veth67de24f. Apr 16 10:28:06 Atlantis kernel: docker0: port 1(veth6f25b29) entered blocking state Apr 16 10:28:06 Atlantis kernel: docker0: port 1(veth6f25b29) entered disabled state Apr 16 10:28:06 Atlantis kernel: device veth6f25b29 entered promiscuous mode Apr 16 10:28:06 Atlantis kernel: IPv6: ADDRCONF(NETDEV_UP): veth6f25b29: link is not ready Apr 16 10:28:06 Atlantis kernel: docker0: port 1(veth6f25b29) entered blocking state Apr 16 10:28:06 Atlantis kernel: docker0: port 1(veth6f25b29) entered forwarding state Apr 16 10:28:06 Atlantis kernel: eth0: renamed from veth9d8220e Apr 16 10:28:06 Atlantis kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth6f25b29: link becomes ready Apr 16 10:28:08 Atlantis avahi-daemon[6289]: Joining mDNS multicast group on interface veth6f25b29.IPv6 with address fe80::80e3:9ff:fe4f:1367. Apr 16 10:28:08 Atlantis avahi-daemon[6289]: New relevant interface veth6f25b29.IPv6 for mDNS. Apr 16 10:28:08 Atlantis avahi-daemon[6289]: Registering new address record for fe80::80e3:9ff:fe4f:1367 on veth6f25b29.*. How do I find out which one of my dockers is docker0?