klingon00

Well, I can't explain it. I tried a bunch of things and nothing worked. I got busy with other things for a couple of days and I just sat down to try and figure the issue out and I noticed it's now working after several days of not working. I'm flabbergasted.

I like others have used Space Invader's instructions for setting up this container and everything has been fine for years until just recently after I applied the latest update to SWAG. I can still access my sites remotely from another network but I'm unable to access them from within my network. All I receive is that the connection was refused and to check my proxy settings. (ERR_CONNECTION_REFUSED) Any assistance here would be greatly appreciated.

I may be the blind leading the blind here but I had the same issue and know just enough to be dangerous. I tried running: mysql_upgrade -u root -p --force After entering my mariadb root password, it seemed to do something with lots of "OK" messages. I restarted the container and then checking the same log mentioned in /config/databases/ now shows what looks like positive things instead of the error about length mismatches over and over. It would seem that resolved the issue.

I was never a fan of ATT provided router/access point that they forced me to use back when I had them. I ended up building a pfSense box and setup the ATT router with a DMZ for my pfSense box. This allowed me to handle port forwards directly from my own router. Unfortunately we are getting into general networking setup and a little out of the scope of Nextcloud container support specifically.

https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/ Vulnerability seems to impact all Minecraft Java edition servers. In order to mitigate vulnerabilities, users should switch log4j2.formatMsgNoLookups to true by adding:"‐Dlog4j2.formatMsgNoLookups=True" to the JVM command for starting the application. What is the easiest way to add this in Mineos? I've also posted on Hexaparrot's repository to increase awareness.

Is there a way to update the version of documentserver within the container? It looks like this container is at version 5.4.2 but OnlyOffice Documentserver appears to be up to version 6.4 now? Thanks

Is this a possible concern with Unraid? https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/sequoia-a-local-privilege-escalation-vulnerability-in-linuxs-filesystem-layer-cve-2021-33909 It would seem most Linux distributions are vulnerable from 2014 onward. If I understand it correctly, this would mostly be a concern if you have untrusted local user accounts in Unraid, correct? If my users only connect using accounts on docker services, would this be less of a concern?

Just posting an update: After a few days of waiting, I attempted another update and this time it was successful. Not sure what went wrong previously but it looks good now.

I'm having the same issue. I noticed an update was available and when I attempted to apply the update it froze during the process saying it had downloaded 0 of 0 bytes and the process never continued after that. I killed the browser tab and went back in and found the MariaDB docker missing entirely. I put it back via previous apps feature, but it still said an update was available and attempting to update caused it to freeze then disappear again. I'd also like to know how to properly update or what I may have done wrong. Thanks.

Yes, I've got both in the container advanced view extra parameters settings. I've ripped many disks before having issues with this one boxed set. Seems something is somehow different than the others.

I was trying to rip a DVD and MakeMKV container kept ejecting the disk right away and the logs keep saying: Error 'Scsi error - ILLEGAL REQUEST:READ OF SCRAMBLED SECTOR WITHOUT AUTHENTICATION' occurred while reading 'BD-RE HL-DT-ST BD-RE WP50NB40 1.01' at offset '1048576' More detail below: [autodiscripper] Disc detected in drive 0 (/dev/sr0): DS9S1D1. [autodiscripper] Starting disc rip... [makemkvcon] MakeMKV v1.15.1 linux(x64-release) started [makemkvcon] Current operation: Scanning CD-ROM devices [makemkvcon] Current action: Scanning CD-ROM devices [makemkvcon] Current progress - 0%, Total process - 0% [makemkvcon] Current progress - 100%, Total process - 0% [makemkvcon] Current progress - 100%, Total process - 100% [makemkvcon] Error 'Scsi error - ILLEGAL REQUEST:READ OF SCRAMBLED SECTOR WITHOUT AUTHENTICATION' occurred while reading 'BD-RE HL-DT-ST BD-RE WP50NB40 1.01' at offset '1048576' Killed [autodiscripper] Disc rip terminated with failure. [autodiscripper] Ejecting disc from drive 0 (/dev/sr0)... [autodiscripper] Disc ejected. What's interesting is that I tried the same disk on Windows and MakeMKV gave the same error (different drive). I then tried running MakeMKV as administrator in windows and it ripped fine. I then tried to run the MakeMKV container as privileged mode on Unraid and it too seems to be working fine. Is there some way I can get this to work without resorting to privileged mode?

I can temporarily get the server working again by running chown -R of the minecraft directory on my appdata share to a local user ID and group 1000. I discovered this works because the docker sets these permissions when you create a new server. Unfortunately, there is some automatic process somewhere that is resetting permissions back to 'nobody' and group 'users' for this directory breaking the docker from being able to see my servers or download profiles, etc. This process appears to be within the docker itself as the permissions get reset every time the docker is started. I've gone through things like CA Backup tool and told it to not shutdown this docker and that has helped the servers to stay up longer but sometimes my players find the server is down randomly and I still have to go back in and fix the permissions manually to get the servers working again. Does anyone here know why this is happening? If it helps, my logs are full of this: USER_NAME not provided; defaulting to "mc" Created user: mc (uid: 1000) Generating Self-Signed SSL... Generating a RSA private key ..+++++ ...............+++++ writing new private key to '.tmpkey.pem' ----- writing RSA key 2019-12-07 23:00:01,015 CRIT Supervisor running as root (no user in config file) 2019-12-07 23:00:01,015 INFO Included extra file "/etc/supervisor/conf.d/mineos.conf" during parsing 2019-12-07 23:00:01,021 INFO RPC interface 'supervisor' initialized 2019-12-07 23:00:01,021 CRIT Server 'unix_http_server' running without any HTTP authentication checking 2019-12-07 23:00:01,021 INFO supervisord started with pid 1 2019-12-07 23:00:02,022 INFO spawned: 'mineos' with pid 30 2019-12-07 23:00:03,401 INFO success: mineos entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2019-12-08 03:00:06,716 WARN received SIGTERM indicating exit request 2019-12-08 03:00:06,716 INFO waiting for mineos to die 2019-12-08 03:00:06,726 INFO stopped: mineos (terminated by SIGTERM) USER_NAME not provided; defaulting to "mc" mc already exists.

My 3900x on ASUS Prime x470 Pro works with GPU passthrough just fine with Nvidia cards on the latest bios with 1.0.0.4b AGESA. I’m currently running 2 VMs simultaneously with passthrough on a GTX 1650 Super (top slot) and a GTX 950 (middle). I’m working on getting a third GT 710 working if I can resolve IOMMU grouping issues with the bottom PCIe slot going through the chipset. This seems to be on all AMD motherboards however with passthrough on the chipset. Some AMD GPUs experience a reset bug where rebooting a VM puts them in an unusable state and the server must be rebooted to become usable again but Nvidia cards don’t seem to have this issue. In my case, my 570 card was working fine with a 1700x on the Asus x470 motherboard but when I upgraded the bios to support the 3900x, the 570 would no longer reset giving -127 errors, forcing me to switch to Nvidia.

Update: I finally got fed up with the crashes associated with GPIO passthrough and the suggestions that i'm fighting the old AMD reset bug are correct. I managed to dig an old EVGA GTX 950 out of storage and put that in instead of my RX 570 card... and my VMs work just fine now. I'm able to reboot them at will, swapping which VM's can use the card all works fine, all without crashes, high CPU usage or black screens! So I guess it's Nvidia for me again for a while. I was hoping to stick with the AMD card since the hack VM works so much easier with it but I've been down this road before... Nvidia net drivers for Mac aren't exactly the best... So to clarify: AGESA 1.0.0.4B has fixed my passthrough issues on my 3900x on an ASUS Prime x470 Pro motherboard. AMD GPU reset bug is still an issue in Unraid however but Nvidia cards work fine.

I've got 2 issues and I'm running the MineOS-Node docker container and fix common problems keeps giving me the following error: 1. If I apply the fix it then gives me this: Back and fourth with no end in sight. Any ideas on what is causing this and how to fix it? 2. Also something keeps resetting the ownership on my appdata/minecraft directory to nobody:users and the docker refuses to see any of my servers unless I manually change the ownership back to a local userID:1000 which is what the docker sets a new server ownership to by default.

Update: I just upgraded my Asus Prime X470 Pro / Ryzen 3900x with the latest 1.0.04B AGESA bios and tried GPU passthrough with my AMD RX-570 card. The VM booted fine but when I shut down the VM and attempted to boot it again, the server did something very strange. First the spinning arrows saying the VM was attempting to boot kept going for a very long time. I got no video on the monitor and once in a while a thread on the CPU would max out and then idle. After a while of this, suddenly the CPU briefly went 100% all cores then the VM went into a paused state. Try as I might I could not force quit the VM nor got it to boot. The web interface for my server was very unresponsive and the console seemed to freeze for 30 seconds at a time only briefly updating the contents. I could not get the array to safely stop and eventually the entire server froze and I was unable to get it to respond at all. I was able to reproduce this several times and I'm afraid to do it again for fear of what it may be doing to my parity... Anyone have any suggestions? I suspect this is similar to the reset bug but worse somehow. I only have a GPU and a USB keyboard and mouse directly passed through to the VM. No audio, no USB cards or anything like that. Interestingly, I did find on the ASUS forum that this version 1.0.0.4B bios has caused problems for users with sound cards that causes the entire system to not boot or to studder and freeze in a similar fashion to what I'm seeing.. I almost wonder if this could be related. Unfortunately, my bios does not have the option to try the suggested fix, disable PCIe Ten Bit Tag Support to see if that's related... https://rog.asus.com/forum/showthread.php?115064-Beware-of-agesa-1-0-0-4B-bios-not-good!/page2

Here is my tale, if it helps someone else: I have an ASUS Prime X470 Pro board that had a 1700x in it along with an rx570 and all was well until I upgraded to BIOS 5220 with AGESA 1.0.0.3 ABBA. I received the well documented "Unknown PCI header type 127" error when running a VM with gpu passthrough enabled. I then upgraded the system to a 3900X with no other changes except for fixing my CPU pinning settings and removing a passed through generic USB device that mysteriously appeared in each of my VM settings. Once I had done that, I fired up my hackintosh VM and surprisingly, Clover booted and displayed fine but when booting into Mac OS the VM got hung up at the apple logo. After a another attempt at starting that VM I received the dreaded "Unknown PCI header type 127" error. I attempted to shutdown Unraid and it also got hungup during shutdown requiring a forced power down. After booting back up, I attempted to boot a Linux Mint VM with GPU passthrough and it booted successfully. I was able to run update the system and run a few program and then I attempted to reboot the VM via the start menu and the screen went dark and it never came back. I performed a force shutdown of the VM and tried to boot it and once again I get the error "Unknown PCI header type 127". So far this is as much testing as I've been able to do. It seems I'm getting a bit farther than some in this, but the issue still isn't solved, even with the latest AGESA update.

I've been running a MineOS-node server for a long time, however I just recently noticed that the Web UI isn't responding. I tried removing and re-installing the docker but it didn't have any effect. The servers I had set to run at startup are still responding, I just have no way to manage them from the UI. Am I alone in this issue? what can I check next? Below is my log file: USER_NAME not provided; defaulting to "mc" Created user: mc (uid: 1000) Generating Self-Signed SSL... Generating a 1024 bit RSA private key ........++++++ ...........++++++ writing new private key to '.tmpkey.pem' ----- writing RSA key 2018-06-18 21:48:03,051 CRIT Supervisor running as root (no user in config file) 2018-06-18 21:48:03,051 INFO Included extra file "/etc/supervisor/conf.d/mineos.conf" during parsing 2018-06-18 21:48:03,059 INFO RPC interface 'supervisor' initialized 2018-06-18 21:48:03,059 CRIT Server 'unix_http_server' running without any HTTP authentication checking 2018-06-18 21:48:03,059 INFO supervisord started with pid 1 2018-06-18 21:48:04,060 INFO spawned: 'mineos' with pid 31 2018-06-18 21:48:05,443 INFO success: mineos entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2018-06-18 22:02:58,402 WARN received SIGTERM indicating exit request 2018-06-18 22:02:58,402 INFO waiting for mineos to die 2018-06-18 22:02:58,409 INFO stopped: mineos (terminated by SIGTERM) USER_NAME not provided; defaulting to "mc" mc already exists. 2018-06-18 22:15:15,200 CRIT Supervisor running as root (no user in config file) 2018-06-18 22:15:15,200 INFO Included extra file "/etc/supervisor/conf.d/mineos.conf" during parsing 2018-06-18 22:15:15,208 INFO RPC interface 'supervisor' initialized 2018-06-18 22:15:15,208 CRIT Server 'unix_http_server' running without any HTTP authentication checking 2018-06-18 22:15:15,209 INFO supervisord started with pid 1 2018-06-18 22:15:16,211 INFO spawned: 'mineos' with pid 10 2018-06-18 22:15:17,562 INFO success: mineos entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2018-06-18 22:15:57,459 WARN received SIGTERM indicating exit request 2018-06-18 22:15:57,459 INFO waiting for mineos to die 2018-06-18 22:15:57,462 INFO stopped: mineos (terminated by SIGTERM) USER_NAME not provided; defaulting to "mc" mc already exists. 2018-06-18 22:16:20,203 CRIT Supervisor running as root (no user in config file) 2018-06-18 22:16:20,203 INFO Included extra file "/etc/supervisor/conf.d/mineos.conf" during parsing 2018-06-18 22:16:20,209 INFO RPC interface 'supervisor' initialized 2018-06-18 22:16:20,209 CRIT Server 'unix_http_server' running without any HTTP authentication checking 2018-06-18 22:16:20,209 INFO supervisord started with pid 1 2018-06-18 22:16:21,210 INFO spawned: 'mineos' with pid 9 2018-06-18 22:16:22,588 INFO success: mineos entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2018-06-18 22:17:04,203 WARN received SIGTERM indicating exit request 2018-06-18 22:17:04,203 INFO waiting for mineos to die 2018-06-18 22:17:04,209 INFO stopped: mineos (terminated by SIGTERM) USER_NAME not provided; defaulting to "mc" mc already exists. 2018-06-18 22:24:02,047 CRIT Supervisor running as root (no user in config file) 2018-06-18 22:24:02,047 INFO Included extra file "/etc/supervisor/conf.d/mineos.conf" during parsing 2018-06-18 22:24:02,055 INFO RPC interface 'supervisor' initialized 2018-06-18 22:24:02,055 CRIT Server 'unix_http_server' running without any HTTP authentication checking 2018-06-18 22:24:02,055 INFO supervisord started with pid 1 2018-06-18 22:24:03,057 INFO spawned: 'mineos' with pid 9 2018-06-18 22:24:04,387 INFO success: mineos entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

That may be my problem. My appdata share is residing on the SSD cache. What was faulty about it and what did you do to resolve the issue?

Thanks for the tip. Hmm, somehow MariaDB was missed in my backups. I tried option 2 but there was no change. Can I just re-install the docker or will I need to do Nextcloud as well? If I leave my NextCloud data in place, will I lose information doing this or will I need to re-import my files once I get NextCloud working again?

I just ran the updater the other day to the latest version and now NextCloud fails saying the MySQL server has gone away. When I check the MariaDB logs it is filled and continuing to scroll this: 180318 16:49:32 mysqld_safe Logging to syslog. 180318 16:49:32 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:36 mysqld_safe Logging to syslog. 180318 16:49:36 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:36 mysqld_safe Logging to syslog. 180318 16:49:36 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:39 mysqld_safe Logging to syslog. 180318 16:49:39 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:42 mysqld_safe Logging to syslog. 180318 16:49:42 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:42 mysqld_safe Logging to syslog. 180318 16:49:42 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:45 mysqld_safe Logging to syslog. 180318 16:49:45 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:48 mysqld_safe Logging to syslog. 180318 16:49:48 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:51 mysqld_safe Logging to syslog. 180318 16:49:51 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:55 mysqld_safe Logging to syslog. 180318 16:49:55 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:55 mysqld_safe Logging to syslog. 180318 16:49:55 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:49:58 mysqld_safe Logging to syslog. 180318 16:49:58 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:50:01 mysqld_safe Logging to syslog. 180318 16:50:01 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:50:01 mysqld_safe Logging to syslog. 180318 16:50:01 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:50:04 mysqld_safe Logging to syslog. 180318 16:50:04 mysqld_safe Starting mysqld daemon with databases from /config/databases 180318 16:50:07 mysqld_safe Logging to syslog. 180318 16:50:07 mysqld_safe Starting mysqld daemon with databases from /config/databases Any ideas on what may have gone wrong and how to fix?

I recently ran the new permission tool after having some permissions issues on a file share and accidentally selected all disks. Now my Teamspeak docker isn't working and the logs show permission denied errors. What permissions do I need to set to fix this?

Thank you very much for this tip. This got owncloud up and running for me after being offline for months due to the update downgrade issue.

I'm in the same boat. The default admin password doesn't work. Any help would be greatly appreciated.