Jump to content

sylinen

Members
  • Posts

    12
  • Joined

  • Last visited

Posts posted by sylinen

  1. Further investigating, memtest86 shows memory errors. However, my config is 2 sticks of 16GB DDR4 ECC. Both sticks showed errors in memtest86, both individually and in pairs, and in all slots, which makes me think the memory isn't actually the problem. The odds of 2 sticks failing simultaneously seem very small to me. I've ordered a new stick of ECC DDR4 to try, but I'm starting to think this is a CPU or motherboard issue.

  2. Some other things I've noticed in testing: SSH connections are being refused, and the following code block shows up in the log around the same time as I lose connection to the server: 

    Jan 14 22:14:46 Tower kernel: veth1cd4618: renamed from eth0
    Jan 14 22:14:46 Tower kernel: docker0: port 2(veth6436d01) entered disabled state
    Jan 14 22:14:47 Tower kernel: docker0: port 2(veth6436d01) entered disabled state
    Jan 14 22:14:47 Tower kernel: device veth6436d01 left promiscuous mode
    Jan 14 22:14:47 Tower kernel: docker0: port 2(veth6436d01) entered disabled state
    Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered blocking state
    Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered disabled state
    Jan 14 22:15:01 Tower kernel: device veth6c69648 entered promiscuous mode
    Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered blocking state
    Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered forwarding state
    Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered disabled state
    Jan 14 22:15:15 Tower kernel: eth0: renamed from veth29ff5eb
    Jan 14 22:15:15 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth6c69648: link becomes ready
    Jan 14 22:15:15 Tower kernel: docker0: port 2(veth6c69648) entered blocking state
    Jan 14 22:15:15 Tower kernel: docker0: port 2(veth6c69648) entered forwarding state

     

  3. 5 hours ago, dlandon said:

    You have docker containers needing updates:

    Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application homeassistant has an update available for it
    Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application Pihole-DoT-DoH has an update available for it
    Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application plex has an update available for it
    Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application sonarr-1 has an update available for it
    Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application Stash has an update available for it

    One is pihole.  Update the docker containers and see if it helps.

    Those containers being out-of-date existed before the problem occurred. I updated the containers anyway, no change.

  4. Having some weird networking behavior on Unraid 6.12.6. I'm periodically losing access to the management GUI and SMB shares on my server. The loss of access seems to be for 30 seconds to 3 minutes in duration. Curiously, the Docker containers I have running remain accessible during these outages (both those using custom IP and bridging) and I can still ping the server's IP. I've done the usual reboots, tried disabling bonding, tried only having one NIC connected, tried a BIOS update. Other devices I have that are connected to the same network are not having similar issues. 

    tower-diagnostics-20240113-1351.zip

  5. My binhex-rtorrentvpn container had an error of some kind during an update, and became un-deletable. Created new container to get around the error, different name, no biggie. But the old container still can't be deleted. It doesn't show up when I run "docker images" in the terminal, but I can run "docker inspect" on the container ID given in the Unraid gui. Running "docker rm" on the container ID returns the following error:

    docker rm  7609238e662c
    Error response from daemon: container 7609238e662c9c068960494cd69752316ca56c33b968007e77fd357945593d0a: driver "btrfs" failed to remove root filesystem: Recursively walking subvolumes for /var/lib/docker/btrfs/subvolumes failed: error walking subvolumes: lstat /var/lib/docker/btrfs/subvolumes/aa4b5954e6d2c96970f5ce6ab5071d659f8f99cfddc6de6f670b1d4f58ca8eca/usr/share/webapps/rutorrent/plugins/retrackers/lang/es.js: input/output error

    And the system log shows the following error when I run the "docker rm" command:

    Feb 13 01:27:08 Tower kernel: BTRFS error (device loop2): bad tree block start 0 347701248
    Feb 13 01:27:08 Tower kernel: BTRFS error (device loop2): bad tree block start 0 347701248

    I suspected a problem with my cache pool, but scrubbing the cache showed no errors. Any other way to delete the bad container?

  6. 21 hours ago, dlandon said:

    Windows uses SMB, not NFS.

    Yes, I know, which I why I chose SMB in the drop down when I tried to mount the drive. So, is SMB broken in UD right now?

     

    EDIT: got it to work. Unraid or UD didn't like using the hostname, so I tried using the IP address. That got it to mount. Should've tried that earlier.

  7. Trying to add a remote SMB share from my Windows desktop. UD finds the share just fine, and it shows up in the UD section on the main Unraid screen, but I can't mount the share. The mount button is grayed out. I don't think it's a security problem, as I've tried all the permutations of security settings in UD settings.  

     

    2100165164_Screenshot(41).thumb.png.aabcf29ab9a5a3ee6abf48efe0f95de3.png

     

    tower-diagnostics-20180930-1452.zip

×
×
  • Create New...