bubo

To continue the weirdness: I've been unable to access the WebUI via hostname for 3 days since I performed the upgrade (across multiple reboots both planned and unplanned). After I accessed the WebUI via IP, the hostname allowed access to the WebUI again.

OK, that is weird. It does access via IP! I've never had an issue accessing it via the name before.

Like others, I've been unable to access my WebUI from other computers ever since I upgraded to 7.3.1. When attempting to access the WebUI, I get a 404 error with nginx below the error. Aside from the WebUI problem, my services appear to be functioning correctly. That said, my system has had two unprompted unclean reboots ever since the upgrade - it's difficult to diagnose since I don't normally interact directly with the unRaid GUI without going through WebUI plus the system is almost 10 years old (so I won't be surprised that I'm seeing early signs of hardware failure). Attached is my latest diagnostics file. Please help me resolve the WebUI issue. tower-diagnostics-20260617-1116.zip

I was not specific enough. What I'm requesting is an additional parameter besides the Base Directory option. I'm already using the base directory option in the new template. The behavior of the base directory option by itself is to have the Output folder in the same base directory as the Inputs (checkpoints/loras/embeddings/etc). Many people put their inputs in a SSD to facilitate load times, and some of them may not want to have their generated images output to the same SSD due to size and repeated write concerns. ComfyUI allows for the separation of the Output Folder from the Base Directory folder via the --output-directory command line flag, but in order to utilize that flag to put the Output folder anywhere besides the Base Directory folder in the current Docker template requires an additional field to allow the user to specify where the Output folder resides in the array. As shown in my screenshot, it's not difficult to get it working. However, I think that many users would prefer having that field added as part of the default Docker installation, and the corresponding --output-directory command line flag incorporated into the docker instead of needing to be manually entered into the COMFY_CMDLINE_EXTRA field.

I would like to request that the docker template be adjusted to utilize the --output-directory command line flag to specify an output directory separate from the directory where I store my checkpoints/loras/embeddings/etc. I have my checkpoints/loras/embeddings stored in a directory on a SSD, and I don't want to be writing continuously to that SSD with the output of my image generations. With the addition of the /basedir feature, the default behavior is to have the output folder in the same base directory as the inputs. Fortunately, by utilizing the --output-directory command line flag, we are able to specify a location outside of the base directory to output images to. However, in order to move it away from the same drive as the base directory, the docker needs to have an additional path added to it which points towards where you want to output images to. I've done this on my end as shown in the screenshot: While it was not difficult to work this out, I feel that other users would find it more convenient if the docker config already included the field to identify the output path, and the --output-directory command line flag was built into the docker by default.

+1 from me as well. I feel that if there are supporting packages available on slackware.org and a non-UnRaid dev was able to pull together the necessary package (drivers / config / packages), then the time has arrived for a re-review of native wireless support within the UnRaid system. I do fully believe that there is a lot more that the devs would need to build/configure in UnRaid to make this an Official Feature than what Pourko has done, but I think that the factors which made wireless unfavorable in past dev cycles has changed enough to warrant a re-review. From my perspective, my children are already writing code while in High School and Middle School, and they are looking to pursue Computer Science or Engineering degrees. It's telling that both of them happily chose to give up new video cards in favor of having hardware that is capable of running UnRaid just so that they can have VMs to write code with. Reviewing college options with my oldest shows that network availability in dorm life (which I know COVID will likely alter) is showing mostly poorly maintained and non-upgraded copper in the walls coupled with limited port availability. It feels like more dorms are switching to wireless networks instead of tending to the copper in the wall, and I'd like the UnRaid machines that I build my children to be usable when they leave for college with them.

Some quick questions: 1. Are you trying to access to second map from a VM on the same UnRaid server, another machine in the LAN, or from an external source? 2. What ports are your internal config files pointed to on your second map?

Did someone mention me? I felt a disturbance in my gaming bubble. It's been awhile since I've visited this thread.

I'll try, but I may have to wait until I get home from work to pull the specific examples out. From my memory: 1. Under the original setup for the ARK Docker, all game files were stored in the serverdata path. Something would trigger instances were the folder identified for the serverdata path would have it's permissions changed to a state where I could not even open the folder with my normal user role (both from the unRaid Terminal CMD, and also from where I had previously mapped to it from Windows Explorer). When this occurred, I could issue a chmod 777 command in the unRaid Terminal CMD (I think I SU the command, but it's been awhile since I did it), and this would correct the problem until it was triggered again. 2. When I was building my alternate paths prior to submitting my XMLs to you, ich777, I discovered that whenever the serverdata folder was locked in this manner, the specific paths that I broke out into the admin path would not be locked. I figured the locking trigger was something unique to me, since my unRaid is configured strangely. I didn't think too much of it, but the main reason I moved the Mods folder to the Admin path was to avoid triggering the lock on that folder. 3. When I read that this was happening to another user, it seemed similar enough to my experience that I posted here. Unfortunately, I'm at work right now. If needed, I can recreate what I experienced and give precise commands and paths that I used tonight when I get home.

I have this happen frequently with my ARK server folders. I'm not certain that ich777's container is entirely at fault though. I have learned by splitting folders out of the default paths that this phenomenon seems to reside with the default game install folder(s). When I moved the config and world files for ARK to a separate external path via the docker config, those external folders stopped having their permissions changed. For my ARK instances, I had to log into the unRaid terminal and use chmod to unlock the folders.

The Docker will overwrite certain values if they are populated in the Docker template. 1. What are you using to edit gameusersetting.ini? 2. Which parts of the gameusersetting.ini are being overwritten? (If you suspect that it is the entire thing, then please add a new entry to see if it's deleting anything.) 3. What are the contents of your Game Parameters and Extra Game Parameters fields? 4. Just to check possibilities, what is the path to the gameusersetting.ini that you are using?

That is correct. At this time, the built in Mod Manager for ARK doesn't work right (this is an ARK Dev issue, and the only known fix involves Symlinking folders and running the executable from a specific directory). One thing to be aware of is that ARK Mods require you to start ARK once after you finish the download, to finish the extraction and installation of the Mod. If you do not start ARK once after the Mod download, and wait for it to finish "Installing Mod(s)" (seen in the lower right corner of the menu), then the files you copy over will be incomplete. Also, be aware that if you have Mods on the server and the Mod updates, the server will not be visible to any clients that have the updated Mod until you are able to update the Mod on the server. Updating the server Mod involves the same steps as installing it (download, start ARK, wait for the install to finish, copy files)

In regard to Colony Survival, they did. Unfortunately, at the time that I figured this out they did not have any documentation on the change yet. I found it by finding a comment from the beta for 0.7.0 in their official Discord, as shown in my post here. To recap, Old Syntax: mono "/home/steam/colony_survival_dedicated/colonyserverdedicated.exe" start_server +server.world YOUR_WORLD_NAME +server.name "YOUR_SERVER_NAME" +server.networktype SteamOnline +server.ip YOUR_SERVER_IP_ADDRESS New Syntax: /home/steam/colony_survival_dedicated/colonyserver.x86_64 -nographics -batchmode +server.world YOUR_WORLD_NAME +server.name "YOUR_SERVER_NAME" +server.networktype SteamOnline +server.ip YOUR_SERVER_IP_ADDRESS +server.rconpassword RCON_PASS Unfortunately, I don't know enough about it to know if there are any other flags add/removed from the command line.

This really sounds like a Steam side issue, but can you post your log with this error in it?

I apologize for taking so long to get back to this. Looking in latest.log, I am seeing this segment at the end: [22:50:30] [Server thread/INFO] [net.minecraft.server.dedicated.DedicatedServer]: Loading properties [22:50:30] [Server thread/INFO] [net.minecraft.server.dedicated.DedicatedServer]: Default game type: SURVIVAL [22:50:30] [Server thread/INFO] [net.minecraft.server.dedicated.DedicatedServer]: Generating keypair [22:50:31] [Server thread/INFO] [net.minecraft.server.dedicated.DedicatedServer]: Starting Minecraft server on 192.168.1.137:25565 [22:50:31] [Server thread/INFO] [net.minecraft.network.NetworkSystem]: Using default channel type [22:50:31] [Server thread/WARN] [net.minecraft.server.dedicated.DedicatedServer]: **** FAILED TO BIND TO PORT! [22:50:31] [Server thread/WARN] [net.minecraft.server.dedicated.DedicatedServer]: The exception was: java.net.BindException: Cannot assign requested address [22:50:31] [Server thread/WARN] [net.minecraft.server.dedicated.DedicatedServer]: Perhaps a server is already running on that port? [22:50:31] [Server thread/INFO] [net.minecraft.server.MinecraftServer]: Stopping server [22:50:31] [Server thread/INFO] [net.minecraft.server.MinecraftServer]: Saving worlds Can you try changing the port on your server/docker?