eroc1990

I think it would be best to adjust the templates because it's just a bad look to have used your referral links, especially for apps where you would directly benefit from people using that link. Not to say that your work is worthless, but it'd be a different story if it was your app and not just one for which you're creating a template.

Why was Traffmonetizer published with an affiliate sign-up link associated with it? I get that you're the one publishing this to Community Applications, but that shouldn't entitle you to being able to use your own affiliate link to funnel people over to looking at the project. EDIT: Likewise for Repocket. EDIT 2: And EarnApp. It almost feels like you're trying to take advantage of other users' ignorance to make a quick buck off of your referral links.

Fair point.

Is fixing the power draw display on the chart for DG2 cards still in the pipeline? Everything else appears to be working normally, as you were mentioning above.

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