klingon00

It seems lots of changes breaking this container on the regular with every reboot. I ended up setting the repository to a known good for now: searxng/searxng:2026.6.13-a29cda858 I also kept losing my Flask session signing key for cookies from my settings.yml file so I added the environment variable (type Variable) Name SEARXNG_SECRET Key SEARXNG_SECRET Value Paste in my ultrasecretkey from settings.yml Click Apply. Hopefully this will prevent future config merges from breaking startup and resetting my key.

So I don't know why but I left it alone for the day, and by the next evening, the app store is working again and showing the missing updates. I was able to update all my apps including talk to version 20. Maybe a temporary issue with the app store site itself?

I just updated to 30.0.2 from 29.0.6 and everything seems to have gone fine except I got a bunch of notifications of app recommendations, like 'whiteboard' and 'deck' If I go into the app store, I cant see any new apps and it says my apps are all up to date, yet many aren't updated like Talk which is stuck at version 19. I had to re-enable it as an unsupported app. Anyone know what I did wrong or how I can fix this?

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.

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.

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?