AlphaOmegaKappa

I've followed your instructions, and have made the variable, named it JAVA_VERSION, etc. without a hitch. In addition, the new server I made to test 1.17 has the correct JARs, enough memory allocated to it, and so on. However, when I try to launch the server, it either • Doesn't launch • Launches for about 10 seconds and then stops, leaving no record in the log I'm running the next-to-latest image of the docker (the latest being the one you pushed out a few hours ago), but there's no option for me to update it. Should I reinstall the docker, or is there another solution?

Here you go home-diagnostics-20210522-1015.zip

On version 6.9.2 So I had an issue with my docker services recently; to solve it, I just deleted my docker.img, reinstalled my container images, and everything was good. However, the cache drive is reporting much higher utilization than I would normally expect. Before resetting my docker image, the cache drive was sitting at 27% utilization (55/200gb), but now it's reporting 43% utilization (85/200gb). This conflicts both with what krusader's reporting, as well as the breakdown from a terminal command. The 30gb difference is close to what I've allocated for docker (28gb) so is that potentially a cause? I use my cache drive to store my docker image, appdata, and any downloads (none currently in this case) that are then transferred to my array.

I'm experiencing the same "operation not permitted" error that multiple people in this thread had in late March. Was there ever a concrete solution to the error? I saw several possible solutions in the thread, but none seemed definitive. Here's my logs for reference: [23:03:51] ain/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD' [23:03:51] ain/FATAL]: Failed to start the minecraft server java.lang.RuntimeException: java.nio.file.FileSystemException: .: Operation not permitted at cyg.<init>(SourceFile:98) ~inecraft_server.1.16.5.jar:?] at cyg.a(SourceFile:105) ~inecraft_server.1.16.5.jar:?] at net.minecraft.server.Main.main(SourceFile:117) inecraft_server.1.16.5.jar:?] Caused by: java.nio.file.FileSystemException: .: Operation not permitted at sun.nio.fs.UnixException.translateToIOException(UnixException.java:91) ~[?:1.8.0_282] at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:1.8.0_282] at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:1.8.0_282] at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:837) ~[?:1.8.0_282] at cyg.<init>(SourceFile:96) ~inecraft_server.1.16.5.jar:?] ... 2 more

I just checked, and the main folder where the files are is set to "Prefer", and was set to "Only" until a month ago. I also made a copy of the server using a different docker, but I'm running into the same error.

Yes, MinecraftBasicServer. No custom versions, just plain vanilla 1.16.5. I'll try to delete the runtime folder and .jar, and then update you. EDIT: The same error occurs, at the same lines, after letting Minecraft generate a fresh runtime and server.jar.

Noticed that my Minecraft server wasn't working, so I cracked open the logs, and noticed that it was calling a null pointer exception. ---Checking if UID: 99 matches user--- usermod: no changes ---Checking if GID: 100 matches user--- usermod: no changes ---Setting umask to 000--- ---Checking for optional scripts--- ---No optional script found, continuing--- ---Starting...--- ---Checking for 'runtime' folder--- ---'runtime' folder found--- ---Checking if Runtime is installed--- ---Runtime found--- ---Checking for Minecraft Server executable --- ---Minecraft v1.16.5 is Up-To-Date!--- ---Preparing Server--- ---Checking for 'server.properties'--- ---'server.properties' found... ---Checking for old logs--- ---Starting Server--- ---Checking for old logs--- ---Starting Server--- ---Waiting for logs, please stand by...--- ---Waiting for logs, please stand by...--- [18:03:01] [Server thread/INFO]: Stopping server [18:03:01] [Server thread/INFO]: Saving worlds [18:03:01] [Server thread/ERROR]: Exception stopping the server java.lang.NullPointerException: null at net.minecraft.server.MinecraftServer.a(SourceFile:572) ~[servernew.jar:?] at net.minecraft.server.MinecraftServer.t(SourceFile:599) ~[servernew.jar:?] at zg.t(SourceFile:567) ~[servernew.jar:?] at net.minecraft.server.MinecraftServer.w(SourceFile:707) ~[servernew.jar:?] at net.minecraft.server.MinecraftServer.a(SourceFile:257) ~[servernew.jar:?] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_261] Terminated Any idea how to solve this?

The .crt file would be ca.RSA.2048 right?

So I feel like other people have been having the same issue, but I've tried some of the fixes in this and the qbittorrent thread to no luck. I use PIA and recently the WebUI of deluge and qbittorrent won't load when I enable the VPN in the container settings, but it will when I disable it. I downloaded the most recent OpenVPN config files from PIA, with no luck. I also changed the files from Toronto to Ontario, as someone mentioned in this thread, also to no luck. Removing the container image and deleting all files with the CA cleanup utility and starting fresh also did nothing. Before the issue, I had set VPN client to OpenVPN in the settings, which seemed to cause a lot of errors in the logs when I noticed the WebUI stopped working (first image). Changing the client to Wireguard stopped the errors, but didn't fix the issue (2nd screenshot). I only had the chance to grab screenshots from qbittorrent, but everything's the same in my deluge container and only this thread has mentioned the issue so far. Run Command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-qbittorrentvpn' --net='bridge' --privileged=true -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='p9059745' -e 'VPN_PASS'='Pchmielparry1' -e 'VPN_PROV'='pia' -e 'VPN_CLIENT'='openvpn' -e 'VPN_OPTIONS'='' -e 'STRICT_PORT_FORWARD'='yes' -e 'ENABLE_PRIVOXY'='yes' -e 'WEBUI_PORT'='8080' -e 'LAN_NETWORK'='10.0.0.0/24' -e 'NAME_SERVERS'='209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1' -e 'VPN_INPUT_PORTS'='' -e 'VPN_OUTPUT_PORTS'='' -e 'DEBUG'='false' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '6881:6881/tcp' -p '6881:6881/udp' -p '8585:8080/tcp' -p '8118:8118/tcp' -v '/mnt/user/data/torrents/':'/data':'rw' -v '/mnt/user/data/torrents/':'/data/torrents/':'rw' -v '/mnt/user/appdata/binhex-qbittorrentvpn':'/config':'rw' --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-qbittorrentvpn' 9f17edc8fb8baa0a4136f909c6f274d3830d8042a5733616e7cb2a580d09f054 The command finished successfully! I also attached pics of the ports and OpenVPN within Appdata. This is probably a pretty minor issue with something that I'm overlooking. home-diagnostics-20210425-2215.zip

Sorry, I run 2 different templates, here's the correct run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='plex' --net='host' -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'VERSION'='docker' -e 'NVIDIA_VISIBLE_DEVICES'='' -e 'TCP_PORT_32400'='32400' -e 'TCP_PORT_300'='300' -e 'TCP_PORT_8324'='8324' -e 'TCP_PORT_32469'='32469' -e 'UDP_PORT_1900'='1900' -e 'UDP_PORT_32410'='32410' -e 'UDP_PORT_32412'='32412' -e 'UDP_PORT_32413'='32413' -e 'UDP_PORT_32414'='32414' -e 'PUID'='99' -e 'PGID'='100' -v '':'/movies':'rw' -v '':'/tv':'rw' -v '':'/music':'rw' -v '':'/transcode':'rw' -v '/mnt/user/appdata/plex':'/config':'rw' 'linuxserver/plex' 711d152c358eeed8ede694a8839db04a14943c6f63b3aef30efd5d74cc1f879c The command finished successfully!

Yeah there's a few left (mostly dockers I don't really use) so I'll have to transfer it. Gotcha, that'd make sense, which is why I saw the 2 different dated libraries within my appdata share. I do, just ran a backup from a version before I made the edit. Unfortunately no luck, same problem as before.

Here it is! root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker create --name='Plex-Media-Server' --net='host' -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'PLEX_CLAIM'='claim-[Claim code redacted]' -e 'PLEX_UID'='99' -e 'PLEX_GID'='100' -e 'VERSION'='latest' -v '/tmp':'/transcode':'rw' -v '/mnt/user/data/media/':'/data':'rw' -v '/mnt/user/appdata/Plex-Media-Server/':'/config':'rw' 'plexinc/pms-docker' 728c7e77866761a818d19d7b2a29cc6b66500dc165846f499c84e9f87d5f89ff The command finished successfully!

Got it, thanks very much, I've attached it below. home-diagnostics-20210405-2145.zip

Sorry for the basic question, but where would I get the diagnostics (is that just the logs)?

Got it, to try and fix the issue I set my appdata user share to "prefer," invoked the mover (which transferred the majority of the Plex files from my array to the cache drive), and then I used krusader to transfer the few files that were left. Howevever, even after I did this and changed the path back to /mnt/user, I'm still running into the same issue.

So this is probably a silly issue, but I changed the config path from /mnt/user/appdata/Plex-Media-Server to /mnt/cache/appdata/Plex-Media-Server. However, I realized that I had installed and set up Plex before I got my cache drive, so some of the appdata files for Plex are still on my array rather than the cache drive. So, I changed the path back to /mnt/user/appdata/Plex-Media-Server, restarted the container and my server. However, I'm given a blank page on my home screen, so it's obviously not picking up on the original appdata. All the original data is still there, so what should I do to fix it? In the 2nd picture you can see the folder with the original data, and it looks like a second folder got created when I made the change.

After a series of file movements that I doubt did anything, the inventories have been recovered. The server is now exactly where it was the moment before it went down. Thank you immensely for your help. You saved my bacon.

@ich777 An update: I followed your instructions as described, and it worked! The server can be accessed and played on. I even managed to successfully edit server.properties using Atom. The only issue is that the player inventories seem to have been rolled back to when I first launched the server about three months ago. I'm addressing that now.

@ich777 A brief question: when I delete the nonfunctional container, should I also delete the image?

TextEdit on Mac, which is the default. I'm trying that now. Just to be safe, I'm downloading the entire contents of the first container (so I don't have to rewrite ops privileges, etc.), but I'll only be inserting the actual world, per your recommendation.

@ich777 I tried accessing it with both the public IP and private IP only available to device on my LAN, to no avail. But at this point, there's another issue. I edited the server.properties of the test container to give it access to the different port, and now the test container is having the identical issue. So it seems like editing server.properties in any way makes the container unable to detect it. That also makes the possible solution of migrating the world file to a new container unfeasible, since the moment I decide to change any server settings, the container won't work. EDIT: I would also like to add that the original problem cropped up after I had backed up the dockers on the server, which was itself after updating the OS to 6.9.1, along with updating all the dockers. Could the updated version of the Minecraft docker be causing an issue?

Alright, so after making a new container with its own port and name (and after fiddling with the EULA and .jar file so they get detected), the new server seems to work. Feel free to read the logs for yourself: ---Checking if UID: 99 matches user--- usermod: no changes ---Checking if GID: 100 matches user--- usermod: no changes ---Setting umask to 000--- ---Checking for optional scripts--- ---No optional script found, continuing--- ---Starting...--- ---Checking for 'runtime' folder--- ---'runtime' folder found--- ---Checking if Runtime is installed--- ---Runtime found--- ---Checking for Minecraft Server executable --- ---Minecraft v1.16.5 is Up-To-Date!--- ---Preparing Server--- ---Checking for 'server.properties'--- ---'server.properties' found... ---Checking for old logs--- ---Starting Server--- ---Waiting for logs, please stand by...--- [13:52:16] [Worker-Main-10/INFO]: Preparing spawn area: 83% [13:52:16] [Worker-Main-13/INFO]: Preparing spawn area: 83% [13:52:17] [Worker-Main-10/INFO]: Preparing spawn area: 83% [13:52:17] [Worker-Main-13/INFO]: Preparing spawn area: 83% [13:52:18] [Worker-Main-11/INFO]: Preparing spawn area: 84% [13:52:18] [Worker-Main-10/INFO]: Preparing spawn area: 88% [13:52:19] [Server thread/INFO]: Preparing spawn area: 93% [13:52:19] [Worker-Main-10/INFO]: Preparing spawn area: 97% [13:52:19] [Server thread/INFO]: Time elapsed: 9702 ms [13:52:19] [Server thread/INFO]: Done (9.781s)! For help, type "help" I can't actually join the Minecraft server and confirm this per se, since the private IP of my server is already being used for the original, nonfuctional container, but the actual logs indicate that the test container works. At this point, what should be the course of action? Should I change the world file in the test container to the world file in the original container, and go from there? Or should I do something else?

Just to be clear, does that involve creating an entirely new Minecraft container, with different ports, directory, etc?

A new server.properties isn't made when the container is restarted/turned back on. The folder that the minecraft server is in is set to Only: Cache.

I tried both • Saving server.properties to my downloads, deleting it from the Minecraft folder, and running the container; and • Saving server.properties to my downloads, deleting it from the Minecraft folder, putting it back into the Minecraft folder from my downloads, and running the container and neither fixed the issue.