d8sychain

@Shirkie I'm sorry I haven't gotten back sooner. I'm in the middle of a large remodel/construction project in between my day job and everything else. I haven't touched development on this since February, so it's going to take me a min to get my head back into the code re-familiarize myself with it and I just don't have the time to do so right now. I have newer code / version, that has quite a few improvements and features than the "latest" build. Its version is "edge". I never merged the new code due to I hadn't finished updating all of the documentation that goes along with it. That being said, if you use the "edge" version it should eliminate any permission problems that your having. I've done quite a bit of testing and use "edge" version in 3 wiki projects of my own, and "edge" is solid with several built in tools/features to ease managing to mediawiki docker, it just lacks the updated documentation on how to use said features. Highlights: Bumping to Alpine v3.11 (lsiobase/nginx:3.11) Added OPTION to add MariaDB(MySQL) built into the container, providing a one-container-does-all, or you can run a separate MariaDB(MySQL) server (NEW FEATURE) MediaWiki Maintenance CLI Menu (NEW FEATURE) ExtensionManager (ENHANCED FEATURE) Backup functions (NEW FEATURE) Database functions (NEW FEATURE) Services functions (NEW FEATURE) MediaWiki file upload, logo, favicon settings changed see Change Log for details If you are not to invested in the current docker version for your wiki, I suggest starting with a fresh version of "edge" -> d8sychain/mediawiki:edge. It is possible to change over from "latest" to "edge", but there are some manual steps have to be taken, like deleting some files so that they get replaced with newer versions. They won't get replaced automatically just in case the end user has made any customization to the files to fit their specific needs , such as the NGINX config file.. If you have anymore problems or questions, don't hesitate to ask. I'll do what I can to answer them, just bare with my time constraints at this time.

I'll try to get back with you tomorrow evening.

Here was my steps: Remove the container and image click Add Container and select the hydra2 template change/update the Repository to linuxserver/nzbhydra2 click Apply Nothing else in the template needs to be changed, and no files or folders have be moved/copied, or renamed btw, I already had backup

Sharing with the community in case someone hasn't seen this yet. https://nextcloud.com/blog/urgent-security-issue-in-nginx-php-fpm/

@Bigsease30, I got MediaWiki working with the official MySQL image, although I had to jump through some hoops to get there. It requires a modification to the default configuration for MySQL 8.0.4 and above. See MySQL 8.0.4 : New Default Authentication. I'll outline what I did. Edit the MySQL template on UnRaid Create a new text file in `/mnt/user/appdata/mysql/conf.d` and name it something.cnf Edit the file and add the following: [mysqld] default_authentication_plugin = mysql_native_password Change the file permissions, if global has write permission MySQL will ignore the file Something like `chmod 644 something.cnf` Start the container and wait for it to run through the Entrypoint.sh script (took a few minutes) Check the container log and look for `[System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.18' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server - GPL.` Then it's ready If you have already started the container before creating the configuration file Stop the container Remove all of the database files in `/mnt/user/appdata/mysql/database` Restart the container Then you can use the MediaWiki installer to connect and complete the installation So, an alternative to all of that, use an older version of MySQL like 5.7 . MediaWiki currently supports MySQL 5.5.8+ Had no issues with MySQL 5.7

@Bigsease30 Nevermind, I see that Bungy made several CA templates for several different images including the official MySQL image.

I use linuxserver/mariadb for 3 wikis, and then use SQLite built into the MediaWiki docker for one that I run just for developing and testing. I also use linuxserver/mariadb for 2 NextCloud containers. So I have 5 linuxserver/mariadb containers running on one server, each one just set to a slightly different host port number. When I get a chance and I will try the MySQL docker that you where trying to use and see what happens. In your screenshot previously, it shows that you were trying to use the official mysql image. Could you clarify?

My apologizes there. I have been working on changes to the docker all weekend and an updated/more informational README. Including instructions more specific to UnRaid, considering UnRaid is what I built this docker for. Also changes to the nginx.conf On MediaWiki installer set your Database host: 10.30.30.30:3306 (although if you are already using that port for a different MySQL container for NextCloud edit your MySQL database template that you are using for MediaWiki to say 3310 first then use the MediaWiki installer) Database username: root Database password: MY-PASS (based on the screenshots you provided). If you have any further problems let me know and I will try to help you through them as soon as I can. Also note, I just pushed new changes to docker tags `latest` and `1.33` (both are the same) late last night without realizing that going from 1.33-2 or older to 1.33-3 may cause problems for end users. If you haven't managed to get through the MediaWiki installer yet, then update the container 1st and delete /config/nginx/nginx.conf before proceeding then everything should be good. If you have completed the installer already and started using MediaWiki, delete the following files: /config/www/mediawiki/ExtraLocalSettings.php , /config/nginx/nginx.conf , Remove line 163 # Load extra settings and line 164 require ExtraLocalSettings.php'; from LocalSettings.php ,then restart the container. Any pages that you may have made in MediaWiki are all stored in the database and retained. Sorry for any inconvenience.

The only part of the README that does not really apply to UnRaid is the docker run commands. Using CA and the UnRaid UI to add the container takes care of the docker commands. Point and click, browse to the URL for the container, use the Mediawiki installer to generate your LocalSettings.php file, download it to /mnt/user/appdata/mediawiki/www/mediawiki/ on your UnRaid machine (default) and you have a running wiki site.

Application Name: MediaWiki Application Site: https://mediawiki.org/ Docker Hub: https://hub.docker.com/r/d8sychain/mediawiki/ Github: https://github.com/d8sychain/docker-mediawiki Note: No longer requires a database container such as MySQL. You can use SQLite that is built into the docker image. Mediawiki supports SQLite, MySQL, MariaDB, PostgreSQL databases. For setup guide please see the README on Github. Status: Beta I am considering this docker as beta for the time being. Mediawiki itself is fully functional and able to be used in a production environment, however, I have not tested / used all the extensions that are included with the core Mediawiki repository. Some of the extensions may require additional libraries and/or additional configurations to function. See the documentation for a particular extension. Change Log: CHANGELOG.md Known Issues: KNOWNISSUES.md Updating the docker image from a version before 10/21/2019 (1.33-3) see CHANGELOG and KNOWNISSUES

Read through this whole thread. Have the same issue of the docker.img file becoming bloated / full. I used this, but moved up one directory and found a 12G .log file find /var/lib/docker/ -type f -size +50000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }' /var/lib/docker/containers/60d8cc72b42ba65bd7d32d60f4da671268293777ea5e67027c2b630eec2dd041/60d8cc72b42ba65bd7d32d60f4da671268293777ea5e67027c2b630eec2dd041-json.log: 91M /var/lib/docker/containers/2d0c7fff7cc76740fb7a49b94fb97441fc8dd51d5723532b290d38bbef979d3c/2d0c7fff7cc76740fb7a49b94fb97441fc8dd51d5723532b290d38bbef979d3c-json.log: 12G /var/lib/docker/btrfs/subvolumes/4d7990cb80ec57c6e13325308389eafb1f783097818aa2c855f8684045cb0ec1/tmp/x11rdp/x11rdp_0.9.0+devel-1_amd64.deb: 66M /var/lib/docker/btrfs/subvolumes/f26230f4f65eafdf3ec5ed86ce1c344d460fe592340c92f95c0d2868b89b7537/var/cache/locate/locatedb: 65M After deleting the 12G file, I checked the webui and it still showed 94%. Disabled and re-enabled Docker and jumped back down to 36%. I don't know container created this file as I don't see any IDs that match it. Either way, it's much better (for now) than starting over with my docker.img and then having to re-add all of my 15+ containers

Actually what I should have done was much simpler. I edited my original post and listed a much simpler solution.

CHBMB, I completely agree, using a backup would have been much better. Dumb (and laziness maybe) on my part. That however has been took care using CA, scheduled weekly. I tried using docker exec -it mariadb bash mv /config/log/ /config/log-old/ exit docker restart mariadb as you had mentioned in the MariaDB thread but it didn't work for me. Everything executed fine and I didn't have any problem with the command lines, but the problem file wasn't in 'config/log/' it was in 'config/databases/'. It was 'ib_logfile0' that was causing the issue. After the container recreated all of the files (because I changed the AppData Config Path in the template). I stopped and started the container, replacing each file in there, one at a time, with the old (original files) in between each start and checked the log files until the issue came back. Once I put the original 'lb_logfile0' in '/databases/' the the issue started again. Here is what I found on those files "What exactly are iblog files in mysql" I was still unsure why I had to fix the dbuser and dbpassword for NextCloud to work, until I looked into things further. MySQL stores the user info in its own database. Although I have not tested this, I should have just copied over both the 'mysql' and 'nextcloud' folder and that would have saved some steps

Although the issue is resolved and NextCloud is up running again, I'd be interested any comments on if there was a better way to have fixed it

Not step by step of everthing I did, because there was some trial and error, but here is what I found to get NextCloud running again. Issue: NextCloud quit working using MariaDB (I still don't know the root cause of what triggered this exactly other than a corrupt file) Errors: NextCloud: HTTP 500 error All NextCloud clients fail to connect NextCloud docker log: 2017/08/27 16:14:19 [error] 306#306: *250 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [1045] Access denied for user 'oc_nextcloud'@'172.17.0.1' (using password: YES) in /config/www/nextcloud/lib/private/DB/Connection.php:61 Stack trace: #0 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect() #1 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion() #2 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform() #3 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\DBAL\Connection->getDatabasePlatform() #4 /config/www/nextcloud/lib/private/DB/Connection.php(148): Doctrine\DBAL\Connection->setTransactionIsolation(2) #5 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverM... PHP message: PHP Fatal error: Uncaught Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [1045] Access denied for user 'oc_nextcloud'@'172.17.0.1' (using password: YES) in /config/www/nextcloud/lib/private/DB/Connection.php:61 Stack trace: #0 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect() #1 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion() #2 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform() #3 /config/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\DBAL\Connection->getDatabasePlatform() #4 /config/www/nextcloud/lib/private/DB/Connection.php(148): Doctrine\DBAL\Connection->setTransactionIsolation(2) #5 /confi This would repeat over and over MariaDB docker log: 170827 14:36:56 mysqld_safe Logging to syslog. 170827 14:36:56 mysqld_safe Starting mysqld daemon with databases from /config/databases 170827 14:36:57 mysqld_safe Logging to syslog. 170827 14:36:57 mysqld_safe Starting mysqld daemon with databases from /config/databases 170827 14:36:58 mysqld_safe Logging to syslog. 170827 14:36:58 mysqld_safe Starting mysqld daemon with databases from /config/databases 170827 14:36:59 mysqld_safe Logging to syslog. 170827 14:36:59 mysqld_safe Starting mysqld daemon with databases from /config/databases 170827 14:37:00 mysqld_safe Logging to syslog. 170827 14:37:00 mysqld_safe Starting mysqld daemon with databases from /config/databases This also would repeat over and over My explanation: NextCloud quit working because it could no longer connect to the MariaDB database server. The MariaDB mysqld service was not starting and retrying repeatedly, because of a corrupt file. Eventually I determined that /appdata/maria/databases/ib_logfile0 was the cause by replacing the files in ../databases/ one at a time (more on that later) New Solution: 1. Stop the NextCloud container 2. Stop the MariaDB container 3. Delete files 'ib_logfile0' and 'ib_logfile1' in '/mnt/user/appdata/mariadb/databases/' (or where ever your '/config/databases/' is located) MariaDB will replace these when restarted 4. Start the MariaDB container 5. Start the NextCloud container <--Ignore This --> I realized later on a lot of this was not necessary and was only needed to fix things that I messed up along the way Old Solution: 1. Stop the NextCloud container 2. Stop the MariaDB container 3. Edit the MariaDB template and change the AppData Config Path (mine was '/mnt/user/appdata/mariadb' I changed it to '/mnt/user/appdata/mariadb-nextcloud') 4. Start the MariaDB container and then stop it again. Let it run for a minute as it starting for the first time basically and creating all the files that belong in the AppData Config Path (see container log) 5. Copy and Paste the folder containing the NextCloud database '/mnt/user/appdata/mariadb/databases/nextcloud' to the new AppData Config Path '/mnt/user/appdata/mariadb-nextcloud/databases/' (I used Krusader, I'm not very good with the command line) 6. Copy and Paste the file '/mnt/user/appdata/mariadb/databases/ibdata1' to the new AppData Config Path '/mnt/user/appdata/mariadb-nextcloud/databases/' 7. Start the MariaDB container 8. Open the config file for NextCloud '/appdata/nextcloud/www/nextcloud/config/config.php and note the 'dbuser' and 'dbpassword' (I used Notepad++) 9. Create a new user in MariaDB and set the username and password the same as it is in the NextCloud config file (I used MySQL Workbench) 10. Set the new user to have full administrative roles 11. Restart the MariaDB container 12. Start the NextCloud container

Tks CHBMB although it didn't exactly help. I did however fix the issue with out having to start over. Some advice, have a backup of /appdata/ , which I didn't have, but do now.

Hey everyone. I'm having a similar problem as mrvilla was, I think. I recently noticed the mobile app was getting unknown error when trying to auto upload photos. I started digging and found NextCloud is not reaching the MariaDB database. Upon checking the MariaDB log, I see 170825 10:59:42 mysqld_safe Logging to syslog.170825 10:59:42 mysqld_safe Starting mysqld daemon with databases from /config/databases and it's repeating over and over, almost every second. I'm not sure where to go from here. I've tried removing both containers and images and, then loading them back, same results. From what I can tell the mysqld is failing and starting over and over. I haven't changed any file permissions (I know better / I learned my lesson one time).