IppoKun

I have an issue with Heimdall that I can't figure out why is it happening and how could I fix it. Basically, I have a reverse proxy with NPMplus pointing to Heimdall (https://sub.domain.xx) and when I access it, Heimdall takes around 8-10 seconds to load. This just happens with Heimdall, all other docker applications using NPMplus don't have this slowness. I edited .env file to include the "https://sub.domain.xx" on APP_URL, but it didn't make any difference. Any ideas?

I rebooted the server and everything is now working fine. 😅

Attaching the logs, same behaviour. kamogawa-srv-diagnostics-20250112-0103.zip

Like the title says, I have two new SSD drives and I want to add these to an existing RAID-0 btrfs pool that already contained two other SSD. All of these drives are 1TB SSD. While trying to find a free hdd slot in my server I disconnected the two existing SSD from the pool, plus other HDD from the main array. I connected all back again in the same slot and I found two free slots to insert my two new SSDs. At this point, all drives that I disconnected and the ones I added were in the unmounted section. I stopped the array, I changed the pool number of disks from 2 to 4, added the two new SSDs in that pool and I started the array back. Now the "fun" happens, one of my HDD from the array was emulated and currently while I'm writing this, the rebuild process is taking care of that issue. But the main issue that I don't know how to solve is that ALL my 4 SSDs from the pool have the "Unmountable: Unsupported or no file system" message: There's also the option of formatting these Unmountable drives, which I DID NOT click: I'm assuming the normal behaviour would be just for the two new drives to appear in this list and just only then I could format using this option. ---- In short now I'm stuck, I cannot go back from 4 to 2 drives in the pool like I used to have in a way to recover my data, nor I know how to proceeed to resolve this issue. I've attached the diagnostiscs file, keep in mind that I have a current rebuild running for one of the HDD drives in the array that I disconnected by mistake. kamogawa-srv-diagnostics-20250110-1731.zip

7DTD, I thought the message wasn't there before. Yesterday there was an update on 7D7D so I had to restart the container to update the server and it kinda got stuck for a while before starting updating the server files.

There was a steam update 1-2 days ago, I also noticed this message appearing. The server still runs anyway.

Yes, for everyone else this is the easier way, I was doing it via shell because I was trying other stuff and it was faster doing it that way 😁

Actually it works, it just that the log viewer doesn't get updated anymore.

@ich777 Used the unraid console feature and used this command: And it didn't get stuck. Weirdly enough it didn't work when I edited out the start-server.sh file to include these flags.

I'm trying to test out 7DaysToDie version 21, but on a clear install the docker after starting gets stuck with the CPU at 100%. This is the output log: Mono path[0] = '/serverdata/serverfiles/7DaysToDieServer_Data/Managed' Mono config path = '/serverdata/serverfiles/7DaysToDieServer_Data/MonoBleedingEdge/etc' Preloaded 'libEOSSDK-Linux-Shipping.so' Preloaded 'libMagick.so' Preloaded 'lib_burst_generated.so' Preloaded 'libgetrss.so' Preloaded 'libsteam_api.so' Preloaded 'steamclient.so' Unable to preload the following plugins: libMouseLib.so Loading player data from /serverdata/serverfiles/7DaysToDieServer_Data/data.unity3d PlayerPrefs - Creating folder: /serverdata/.config/unity3d/The Fun Pimps PlayerPrefs - Creating folder: /serverdata/.config/unity3d/The Fun Pimps/7 Days To Die - Dedicated Unable to load player prefs Desktop is 0 x 0 @ 0 Hz This is the console log: Success! App '294420' fully installed. ---Prepare Server--- ---Moving SaveGameFolder location--- ---Savegame location found--- ---Moving UserDataFolder location--- ---UserDataFolder location found--- ---Server ready--- ---Start Server--- [UnityMemory] Configuration Parameters - Can be set up in boot.config "memorysetup-bucket-allocator-granularity=16" "memorysetup-bucket-allocator-bucket-count=8" "memorysetup-bucket-allocator-block-size=4194304" "memorysetup-bucket-allocator-block-count=1" "memorysetup-main-allocator-block-size=16777216" "memorysetup-thread-allocator-block-size=16777216" "memorysetup-gfx-main-allocator-block-size=16777216" "memorysetup-gfx-thread-allocator-block-size=16777216" "memorysetup-cache-allocator-block-size=4194304" "memorysetup-typetree-allocator-block-size=2097152" "memorysetup-profiler-bucket-allocator-granularity=16" "memorysetup-profiler-bucket-allocator-bucket-count=8" "memorysetup-profiler-bucket-allocator-block-size=4194304" "memorysetup-profiler-bucket-allocator-block-count=1" "memorysetup-profiler-allocator-block-size=16777216" "memorysetup-profiler-editor-allocator-block-size=1048576" "memorysetup-temp-allocator-size-main=4194304" "memorysetup-job-temp-allocator-block-size=2097152" "memorysetup-job-temp-allocator-block-size-background=1048576" "memorysetup-job-temp-allocator-reduction-small-platforms=262144" "memorysetup-temp-allocator-size-background-worker=32768" "memorysetup-temp-allocator-size-job-worker=262144" "memorysetup-temp-allocator-size-preload-manager=262144" "memorysetup-temp-allocator-size-nav-mesh-worker=65536" "memorysetup-temp-allocator-size-audio-worker=65536" "memorysetup-temp-allocator-size-cloud-worker=32768" "memorysetup-temp-allocator-size-gfx=262144" Any ideas?

These ports should be free, since no other docker image is using them. I even tried out host network, added -port 27030 on the GAME_PARAMS, edited also the GAME_PORT just in case and I get the following image (attached). I'm out of ideas it simply does not want to work.

Is it possible that the steamcmd that I re-used (from one of your 7dtd servers) is making something break?

I just tried out two other ports, the default one and 27100. With the default one it works, with the other it doesn't show up. Not sure why.

I did change the default port and I also changed the GAME_PORT. I'll attach some screenshots of the config. I also added the "+sv_setsteamaccount YOURTOKEN" in GAME_PARAMS. I only opened port 28015 (UDP) in my router, but it still doesn't show the server online. If I try to connect manually via console on the game using "connect IP:PORT", I get a message "server only accepting connections from game lobby IP:20715" which I find it weird since I changed the port.

I'm having a port issue (not sure if its the same issue you guys are talking lately) while trying out CSGO server. Server doesn't appear while having port forwarding and everything supposedly set-up correctly. I'm seeing this on the logs: Setting mapgroup to 'mg_active' Unknown command "port" NET_CloseAllSockets ---- Host_NewGame ---- Seems the +port command is not correctly identified?

No. Like I said everything works doesn't matter what port I choose. At first I was using the default port (26900) and that was working just fine, but after like 3 days it stopped working and I had to change to 26901 (I mapped the correct ports on docker). After couple of weeks without any problem, today it stopped working and I changed back to port 26900 and now its working again. It feels like there's a sort of firewall flagging something and blocking the port, but I don't have any firewalls (from router to unraid), so I don't understand this issue and its hard to diagnose

I'm having an issue that is really hard to figure it out. I have a 7 days to die server up and running, NAT port forwarding is properly set-up and working fine, everyone can join and see the public server on the server list. The issue happens very randomly, out of the blue the game query port stops responding to queries and thus the server stops showing up on the server list, all of this without any changes at all on my side. Restarting the docker image doesn't solve it, nothing seems to solve this besides me changing the port to another port (which eventually this happens again and I have to change to another port).

Oh sorry, everything is working for me, I was just reporting the warnings I was seeing on the logs, I should've searched before posting my bad 😅

@ich777 maybe I'm wrong but it seems something changed and the script now should use force_install_dir before the login, according to my logs: Waiting for client config...OK Waiting for user info...OK [33;1mPlease use force_install_dir before logon! Also I'm getting this warning: Warning: failed to init SDL thread priority manager: SDL not found

I'm using plex on docker for the first time and I'm not having the same performance (very nitpicky, more below) as before when I used Plex Server directly from my windows server. More information that might be revelant about the servers: - Both Servers are using a NVMe SSD for the metadata (docker server has a faster NVMe SSD (enterprise vs consumer)) - Regarding the CPUs, docker server has 2xE5-2680 v4, windows server has a i7 4790k - Both servers have the same content to be displayed on the libraries. - Both servers are on the same network, connected to the same switch. I measure the response time it takes on the unraid docker instance to load completely all images in one library with Chrome network tools and this is the response time from my old plex server loading one library (in red is the analytics events that are blocked by adblocker, ignore those): Now the same library but accessing my plex docker instance instead: More details on the 287ms request, we can see the webpage is waiting for the response from the server: Why is this much difference between servers (10x more, but sometimes it spikes even higher) I know I'm being nitpicky here, but I wonder if there's anything else I can do to match the performance I had before. I tried to use bridge mode on the docker plex server but it didn't make any difference. EDIT: I found out this post by @mgutt so I tried it out the direct access tweak, changed my appdata config folder path on plex docker config (/mnt/user/appdata/plex) to (/mnt/cache/appdata/plex) and now the performance matches my old server! I'll leave this post here in case anyone finds the same "issue"