• Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

joshbgosh10592's Achievements


Rookie (2/14)



  1. I removed the container and openrct2 folder and was able to get it to read an old .sv6 file I had previously, but I still get the "Unable to connect to server" error when I connect, but it lets me right in anyway without any other issues. Also, because OpenRCT2 now has their own save format, Name.park, is there anything besides changing the filename within the Docker settings that needs done to get the server to use that file? I tried and it just reverted to my old save file (not the docker default). But if I try to revert the save to the docker default's "docker.sv6", it doesn't honor my change.... Thank you, I really appreciate the help so far!
  2. Assuming you mean /mnt/user/appdata/openrct2/user-data/config.ini, they are set to what I customized it to: player_name = "Josh" default_password = "CustomSecret" server_name = "CustomName" server_description = "Custom Description. advertise = true advertise_address = "" master_server_url = "" That's strange that since the password is on by default for your container, yet I am not prompted to enter it.. I also should note that currently I do not have ports forwarded so I manually entered my NAS's IP address in my OpenRCT2 client to connect locally. However I don't see my server being advertised within the master server. Maybe because the address property is null?
  3. Thank you for looking into it! So, the server customization, such as the name and description (even though it's not prompting for a password or a welcome message, maybe because my client is already a known client with a key?), however the save file specified in the Docker settings isn't being honored for some reason. It keeps defaulting to "docker.sv6" instead of the filename I have listed. Somehow, even after I overwrite the "docker.sv6" with my own file. I'm confused on how that's even possible, unless that save file is cached somewhere..? Might also be something to note, when I do connect to the server running within Docker, I get a "unable to connect to server" red error right away, but it connects anyway.
  4. the appdata share is set to prefer. I'm assuming it should be only? There's been plenty of room on that cache pool though, so it shouldn't have moved to an HDD.
  5. (For OpenCTR2) Not the person who asked the question, but I'm also having that issue. I'm changing that value, as well as other values within /mnt/array_cache/appdata/openrct2/user-data/config.ini, such as default_password (that should require users to enter a password, right?) and it appears that the container is ignoring me partially. server_name, description is working, however.
  6. I'm able to create the first backup without issues, but any backup afterwards just ends up "Preparing Backup" and then Stopping... macOS 12.3.1, unRAID 6.9.1
  7. Yup, sorry, like I said, I felt like a complete noob and was making a stupid, simple mistake. Thank you! I'm very new to dockers and forgot that their data is just a folder inside the appdata share.
  8. I also typically use nano, but when I try to edit it (using the container's CLI), no commands work - not nano, not ping, not even vi. I have a feeling I'm just doing something wrong and it's a simple mistake lol..
  9. I feel like a complete noob, but how do you even edit the nano, vim, nor vi seem to work...
  10. I accidentally filled up a share that uses only a cache pool to the point where unRAID reported I was using something like 3.3TB. The cache pool consists of one 2TB and one 3TB drive in a RAID0 format. Because of the miss-match size, I should have a usable of 4TB (2TB across both disks), right? I emptied the share down to 2.96TB. When I attempt to copy anything to the share on from any client, I receive an error, and when I try to nano via unRAID's CLI, I get Error writing test.txt: No medium found. Because of the issue with unRAID, I've ignored troubleshooting clients' issues, which is why I'm only saying that they return an error. I'm still getting this issue, even after a reboot. I can read perfectly normal from this share. Any ideas? Main page view: Balance Status of the cache pool: fdisk -l returns this for the two disks in ShareHDD (sdh and sdi): Disk /dev/sdh: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: WDC WD20EFRX-68E Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdh1 64 3907029167 3907029104 1.8T 83 Linux Disk /dev/sdi: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: WDC WD30EFRX-68E Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: CFDAB87B-8FBD-4B4F-B745-3C2DC2DF1340 Device Start End Sectors Size Type /dev/sdi1 64 5860533134 5860533071 2.7T Linux filesystem
  11. Yup, that's exactly what happened. Inside the share settings, it shows what I want, but in the share overview, it shows the old share name (You can see where the new share (Share A) I created shows "Array_cache". I toggle it to another cache pool and back, and now I'm writing to the cache correctly (well, for some reason it's moving the files in and back out through the VM instead of just moving it within the NAS. Previously, I was able to move at around 200MB/s while putting no strain on the VM NIC (something like NFS Offload). I'm assuming that's just how I have the shares mapped in the VM?) Thank you!!
  12. So, it's set to use the original cache pool from pre-6.9, however I renamed it once I created the other pools. Could the rename of the cache pool have screwed it up, even though the GUI says it's correct?
  13. I'd rather be slightly generic publicly on the share names (unless my explanation below doesn't make sense and it's just too confusing). Share A is named "T------s" in the configs (short term), and Share B is "M----s" (long term). When I'm done working the files in the short term share (Share A), I copy them to the long term (Share B). This is to prevent the spinning disks in Share B from constantly being awake (and bogged down by the work being performed.
  14. Thank you! Here it is. So this isn't expected behavior then? I know, this is me manually moving files from one share (cache only) to another share (cache enabled, using a different cache pool than original.) Thank you though