eroc1990

The description in the template says nothing of what it is (a password manager for teams). That should be rectified.

I just decided to downgrade to 6.11.5 for now. Leaving it as is, evaluating performance from there, and may try upgrading again at some point in steps to see where the issues really begin to manifest. Thanks for the help though, @JorgeB.

Yup, usually you'd expect better performance. Unfortunately for me, that has not been the case. I've been up-to-date on the BIOS for a while, including prior to installing 6.12.x. I wish I could fix it by updating that. Oh well. I might just wind up manually downgrading back to the latest point release of 6.11 as a result of this.

Isn't it odd, though, that it's just suddenly happening? This would never happen on previous versions of UnRAID.

I'm going to lead by stating that my UnRAID setup is not normal. I don't do pool/cache. UnRAID is basically a container/VM manager for me, with direct /mnt/disk# mappings for mounted volumes in Docker. Recently, I've been running into an issue where BTRFS will just crash on me out of the blue. My system is usually running anywhere between 60-80% memory usage, of which I have 32 GB. My Docker disk image is formatted BTRFS (was XFS for a while, recently changed after a similar XFS crash prompted a rebuild of the image file). Disk 1/2 are formatted XFS, and 3, 4, and 5 are BTRFS. It seems like there's no rhyme or reason to the crashes I've encountered. The server wasn't under excessive load, memory wasn't constrained beyond what I stated earlier. I'll just see my alerting from my VPS telling me stuff's down, and then I refresh and the system logs are filled with BTRFS read/write errors. Per Scrutiny, all disks in my server are healthy, so I don't think it's a drive issue. I haven't extensively tested my memory, but pre-6.12, I would have uptime in excess of 30-40 days between manual reboots, if needed, save for a random crash here or there due to me allocating more resources to something than I meant to. I've attached two diagnostics, one generated automatically when the issue occurred, and another I manually generated post-reboot. Any insight on how I can improve my server's stability would be greatly appreciated. ericserverpc-diagnostics-20230718-1621.zip ericserverpc-diagnostics-20230718-1638.zip

You've got too many nameservers active. If the VPN service doesn't provide you with server addresses that work with this container, try some public one like Quad9 or 1.1.1.1, but make sure to delete the other IP addresses you aren't using.

Startup logs aren't going to give much context. Do you have the logs around when the failure occurred?

Just keep in mind that the last update to this container was three years ago, so tread carefully when installing and make sure you are properly securing your environment.

Any clue if there's a way to define where it saves the temporarily archived data? I'd rather save the files to a folder on one of my drives instead of inside the Docker image disk, especially since there's no upper limit for how much storage the application uses when downloading files to archive.

Is that part of them switching over to those 10. addresses?

Anyone else having issues with the Binhex rtorrentvpn (or any of the Binhex <insert name here>vpn containers) suddenly being unable to resolve PIA? All of a sudden, traffic on my containers dropped to 0, and I've been receiving the following error: 2021-11-07 02:41:10,532 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error This always results in the container giving up and quitting its connection attempts. Is there anyone else that's been running into this kind of issue? EDIT to add: There have been no changes to my Internet service or network configuration. My PIA account is still valid and credentials are accurate. EDIT again to add: So it looks like, for some reason, the PIA DNS servers are not being appended to /etc/resolv.conf when my Binhex containers start. Can't figure out why not, as the containers are running privileged.

Try removing the text characters and slashes, leaving just the IP address of your target. Sent from my iPhone using Tapatalk

Works like a charm! Thanks again for setting this up!

Sounds good. I’ll hold off on implementing this until that’s been updated. I’m glad to see this is a thing now though, so thank you.

Any plans to support CHAP authentication? Or did I miss that the option exists? I'm able to define my target but it won't connect because of the lack of authentication capability.

The only physical connections to my server are network, power, and my boot usb. So unfortunately that’s not it.

Well I tried changing out the PSU. Swapped the OEM 300W out for a 450W EVGA PSU and that failed. Server remained powered on for about an hour and then crashed. I'll have to wait for a bit to swap out the mobo, but that might be necessary at this point.

Temps are fine and all fans are working. PSU I haven’t tried and am hoping I don’t have to, but we will see. I might have to give it a shot at this rate.

Updating with a more recent diagnostic report.ericserverpc-diagnostics-20210723-2233.zip I'm starting to suspect the lsof errors less than before because I no longer see them leading up to the crashes, but I still can't pin down the root cause.

Hey all, I've been running into a somewhat odd issue lately. I'm running Unraid 6.9.2 mainly as a Docker container host, but do utilize it for some file shares on my LAN. I have a QNAP TS-251+ acting as a storage backend for most of the larger data within my Docker containers, mounted as an SMB share through Unassigned Devices. These are both connected to my network via gigabit network connections. Without fail, at least once or twice a day, my server will completely power itself off without my instruction. There are no processes I'm running that would automate a shutdown of the server. I've attached a snippet of my syslog. I'm seeing a number of kernel trap messages that are formatted similar to the following: kernel: traps: lsof[32635] general protection fault ip:14f154227a9e sp:c1118279394e5048 error:0 in libc-2.30.so[14f154208000+16b000] I recently swapped out a 2GB RAM stick I had to 8GB to give myself 16GB total, so I initially thought that might have been the issue, but no matter what combination of RAM I try, it doesn't result in stability lasting for longer than a day. Has anyone else seen this issue before that might be able to point me in the right troubleshooting direction? Thanks!! new 1.txt ericserverpc-diagnostics-20210708-1418.zip

Adding onto this, I've attached the packet capture I ran when trying to connect to the server via NetBIOS name. Same issue occurs when attempting to access by IP address directly. Unraid Negotiation RST ACK.pcapng

Hi all, I previously made this post seeking assistance resolving an issue I had connecting to my unraid sever via SMB. While this still isn't working, I have made anew discovery and am hoping someone has run into this error before and can provide some guidance. I ran a packet capture w/ wireshark and saw that although my Windows 10 PC running 21H1 was sending SYN packets, the unraid server was only responding with RST/ACK instead of the expected SYN/ACK. It keeps requesting re-transmissions of those original packets, which ultimately winds up failing. Anyone have any ideas why computer and my unraid server cannot establish a connection over SMS when my iPhone and iPad both can using the same SMS credentials? Thanks in advance to anyone who takes a crack at helping me with this issue!

Somehow missed the password protected sharing toggle but even after I tried that nothing worked. Like I said the only case where it did actually work was when SMB1 was the only SMB protocol enabled, and I'd rather not drop support for SMB 2/3, since my Qnap NAS (per my configuration) requires a minimum SMB version of 2.1. Disabling anything after 1 would break the bulk of my SMB shares.

Yup, and on top of that everything is already in the same workgroup. Even changed the workgroup across all of my relevant devices to something other than what it was originally (but still the same one across all my computer, Unraid server, and qnap NAS) and it changed nothing. The only time I was able to remotely navigate to it was when SMB1 was the only SMB protocol active, which is not a configuration I’m willing to keep.

Already done. That’s the Lanman workstation fix I mentioned in my initial post.