ShinseiTom

Yeah, this is a server that doesn't (shouldn't) need an account. Unfortunately, Valve screwed something up on their end, so I guess I'll just have to wait. I wasn't able to use the supposed workaround either. And I'm definitely not turning off Steam Guard or bothering to have a secondary account just for this one thing haha. Thanks for looking into the workaround though, I appreciate it!

Is there a way to get around the "invalid platform" error with your Left4Dead2 dedicated server image? Without having to turn off steam guard and logging in as my user. It looks like it's currently a bug with Valve transitioning to a new tagging system for free servers, and there's supposedly a workaround: https://github.com/ValveSoftware/steam-for-linux/issues/11522#issuecomment-2512232264

I've started running into this issue ever since the latest large update (I guess to v7? The one that completely changed the webui theme) Basically, after a random but long (this last time was 4 days) amount of time Grafana goes back to the login screen. This is what I assume is the error messages related to it: t=2020-12-06T03:10:23-0600 lvl=eror msg="Failed to send usage stats" logger=metrics err="Post \"https://stats.grafana.org/grafana-usage-report\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)" t=2020-12-06T04:06:20-0600 lvl=eror msg="Failed to look up user based on cookie" logger=context error="user token not found" t=2020-12-06T04:06:20-0600 lvl=eror msg="Failed to look up user based on cookie" logger=context error="user token not found" Unfortunately, the Grafana devs don't seem to be seeing the same issues on any of their systems so it's probably some kind of "quirk" of the multitudes of personal-run instances and circumstances. Doesn't help us that have the issue though, and definitely shouldn't be happening and didn't in the past. According to a response near the end of this github issue, increasing that "token_rotation_interval_minutes" value to something large (like 7 days) helps mitigate the issue somewhat. But I too can't find the config file (custom.ini? since supposedly we're not to modify grafana.ini) mentioned in their documentation. Is there a way to modify that config setting using the docker setup variables, or at the very least find and modify the config file used through the container's console? Would changing the "GF_PATHS_CONFIG" environment variable to point to a modified config in it's appdata be enough?

Thanks, I was on 0.5, that was the update that killed it. At the time I posted, that reddit response wasn't quite there yet, must have been off by mere minutes based on timestamps! However, it's been updated again and now has a button to redirect to the login page on that unauthorized page! I hoped it would get fixed pretty fast. Now I need to check if my homescreen user problems are fixed.

Dont know if this is just me or not, but I can't use DashMachine at all since the recent update. I just get an "Unauthorized" page when I try to open the site. Tried completely wiping and restarting but still got the same, Firefox and Edge. Sucks, just got it setup with icons and everything.

So, this is an interesting coincidence. I had recently used the advanced option to add the iDRAC 6 docker image to unraid. And it just almost works. It connects, get the needed java libraries/whatever from the iDRAC, but then it fails to actually login I guess? It just gives an unhelpful "Connection failed." in the log. Unfortunately this version does the same thing (as I expected, since it's literally the same thing from domistyle). I know the idrac is working. It's not using anything crazier than a static ip. It's not super out of date, though it's not the newest version. It is just using the default cert. I resorted to setting up a WinXP virtual machine on Unraid instead and it connects just fine and can run the remote control/display part. The only true "fix" to the issue on his github that a user relayed was "reset iDRAC". Which I really just do not want to have to bother doing. So if anybody finds a fix or workaround to this error it would be wonderful. But I have a feeling it's a Dell issue somewhere in their crap that for some reason gunks up what this docker image is doing but doesn't to a normal XP os.

I've not been using Unraid very long, still in the trial phase. I like it since it's so much simpler to use than FreeNAS or similar. So maybe I'm doing something incredibly wrong with this image and MariaDB, but I get just abysmal performance and tons of problems despite following the tutorial as best as I can tell. I first had really bad problems getting Nextcloud to use the db correctly. I'm still not sure it really is using it right. I was doing the initial setup, and it was timing out with a 504 error. But it definitely was connecting and adding tables with data, so I don't know what the issue is. I tried wiping the dockers and their data and completely restarting a few times. Then I tried just doing the Nextcloud setup twice in a row. User/pass already exists (despite being on the initial setup page). So I used a different combo and it finally went through, but only if I logged in using the first time's combo. Ok.... Then I went through the normal setup on a desktop, and it is technically working... but it's just f'ing terribly slow. I know it's not a bandwidth issue, if I throw one large file in there it downloads/uploads super fast just fine. But throw in a folder with even a few hundred small files and it just grinds to a halt. Less than one file per 5 seconds is transferred. And I can hear the drives super thrashing, constantly. Nothing else running on the server does this. It's not a bad drive as I've even tried moving around mapped folders to get it working better. Cache doesn't help. Just straight-up moving the files to the server in an open share is super-fast (for tons of tiny files to non-ssd) and finishes in literal seconds. I'm obviously screwing something up with one of these docker images, but I don't know what. Does anyone have any tips?