I run a similar setup (migrated from a pretty old bare metal OwnCloud install), but without Redis, and using PostgreSQL as backend, and it’s been mostly issue-free.
If you don’t really need it you might want to try dropping Redis, if only temporarily, and see if that helps at all.
I have listed the logs for dockerd here:
I will need to grab nextcloud’s logs after work today.
I will definitely consider dropping Redis, since it’s not a requirement.
It appears that Docker fails at:
ERRO[2021-09-20T21:27:13.996614318-04:00] failed to mount overlay: no such device storage-driver=overlay2
I’m not sure what the deal is all about with graphdriver, but I am guessing it’s more to do with the mounted volume. I would suspect that creating a new container with a new volume, the issue would be reproducible. But again, once you reinstall docker, everything goes back to normal.
I am guessing, just like before, this is an arch / pacman thing. It would be interesting if we could test and reproduce this in Arch, because again, I doubt it’s the service manager, it’s most likely the package manager that screws things up. But again, I could be wrong and I don’t have the energy to look it up.
Alright, here’s where we are currently. Last night, I was unable to get docker daemon running automatically. Had to:
sudo dockerd
and left a Terminal window open to monitor the thing, because it couldn’t be left unattended in that state.
Ran Portainer, it was fine. Ran Nextcould, and it was still having the strange request error. I nuked the Nextcloud setup and started with a new config:
version: '3.2'
services:
nextcloud:
image: nextcloud:latest
container_name: nextcloud
restart: always
volumes:
- /srv/nextcloud:/var/www/html
- /srv/nc_apps:/var/www/html/custom_apps
- /srv/nc_config:/var/www/html/config
- /srv/nc_data:/var/www/html/data
ports:
- "8080:80"
environment:
NEXTCLOUD_TRUSTED_DOMAINS: 10.12.8.3 artixserv.txp-network.ml
MYSQL_HOST: '10.12.8.2'
MYSQL_DATABASE: nextcloud
MYSQL_USER: root
I yeeted the Redis part, just Nextcloud vanilla now. It installed without issue. Stopped and restarted the Nextcloud instance, it was fine. Restarted the Artix VM and started Nextcloud again, no issue. Had to goto bed, because it was way past midnight.
Came back tonight, and powered on the Artix VM. Docker daemon started successfully on its own, and I’m now afraid to:
sudo pacman -Syu
Portainer will most likely work just fine. But that container also autostarts and manages Nextcloud currently (custom stack). Time to see if Nextcloud will play ball.
EDIT: Nextcloud threw the same error as seen here:
It appears to be solely an issue with the Nextcloud instance now. Restarting the Artix VM also had no effect on the functionality of the current setup. It doesn’t appear to be Artix that’s the issue at this point. I’ve created a new compose file once more, because why not:
version: '3.2'
services:
nextcloud:
image: nextcloud:latest
container_name: nextcloud
restart: always
volumes:
- /srv/nextcloud/html:/var/www/html
- /srv/nextcloud/apps:/var/www/html/custom_apps
- /srv/nextcloud/config:/var/www/html/config
- /srv/nextcloud/data:/var/www/html/data
ports:
- "8080:80"
environment:
NEXTCLOUD_TRUSTED_DOMAINS: 10.12.8.3 artixserv.txp-network.ml
MYSQL_HOST: '10.12.8.2'
MYSQL_DATABASE: nextcloud
MYSQL_USER: root
The compose file isn’t really where the difference lies in the approach though. I’m gonna be targeting the MariaDB backend from here on. This is because when I shutdown and bring back up the VM host (ESXi), I also am rebooting the MariaDB host - which would kill any non-persistent settings every time it returns. I also know for a fact that the MariaDB backend is the one consistent factor between all of my recent test runs. I use the same commands to setup the DB:
DROP DATABASE nextcloud;
CREATE DATABASE nextcloud;
GRANT ALL ON nextcloud.* to 'admin'@'remotehost' IDENTIFIED BY 'password' WITH GRANT OPTION;
ALTER DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
SET GLOBAL innodb_read_only_compressed = OFF;
FLUSH PRIVILEGES;
And these commands work for initial runtime, which means that there should be no major issues in how the DB was initially setup. I know the nextcloud DB and its tables aren’t disappearing every time I reboot the VM server, because I have to drop the DB (btw it has ~107 lines/rows initially - memorised that from the thousands of install attempts) every time I nuke and remake Nextcloud (a pain in the @$$). I also know that Character set and Collation should be persistent, so I won’t be focusing on those either. I’m targeting this one:
SET GLOBAL innodb_read_only_compressed = OFF;
I’m not so sure if this setting is persistent on reboots. Only one way to test this. I’ll be back tomorrow with an update. Otherwise, File Run may get another shot at the remote file storage role…
The real test begins now:
Need to try spinning up Nextcloud, to see if that error still shows up after this…
On a side note, Portainer made me pacman -Syu tonight. Couldn’t access it until I caved and did the system upgrade. Was worried that something may break.
If you setup your ESXi and vCenter with just IP addresses initially, and added domain names after-the-fact, this may be of interest to you:
For setting that, and redoing your server’s certs.
It has been a long month since the last update, and a lot has changed. Here’s what has been completed thus far:
activated EaseUS Todo Backup Server for easier backups of Windows Server 2016
created AD integration/query users for Nextcloud, ejabberd, and FreePBX
initiated AD integration config for ejabberd
updated, broke, and revived the Artix VM
kicked F@H from the Artix VM, to re-add it as a container later on
initial planning for the move to ZFS (the entire Artix VM)
purchase the MikroTik RB4011iGS+RM
initiated Samba setup for the Artix VM
And now I’m preparing to move ejabberd to a Docker container. Gonna have to change the OP once the dust settles. Still more to announce, once things get under way…
Just received a MikroTik RB4011iGS+RM in the mail, purchased a MikroTik CCR2004-1G-12S+2XS, and put in an offer for a MikroTik Audience RBD25GR-5HPac, to act as the wireless gateway to my serverside network. Also purchased 50x 12-24 rack screws+cage nuts and 50x 10-32 rack screws+cage nuts. That should be able to mount most of my upcoming equipment…
Just joined the Artix OpenRC VM to the Windows Server AD, with Samba. We’re one step closer to getting the Artix VM ready for production use.
Now I need an automated way to assign the following to existing AD objects, and new ones on-the-fly:
These RFC 2307 attributes are going to be required for single identity across the setup in the future if I go with Samba. With this, I will be able to enhance the user experience further…
U wot m8?
Simple picture with no context. I guess that’s a good enough update. At least your cable management is top notch. Can’t have a rats’ nest of cables if you got no cables.
Can’t wait to see the update on your rack.
The item, that is two spots down from the DL580 G7, is a new addition. It has a Threadripper 1920X in it, and will have ESXi installed to it sometime this weekend if I have my way. The router sitting at the top of the rack is another new addition that happened today. I’ve got two more pieces of networking equipment on the way, that will go directly underneath that router.
On the cable management part, I’m routing all of my cables through the rear of the rack. I’ll be grabbing 1-2 PDUs and come cable management arms in the beginning of 2022.
I got AD/LDAP integration working in Nextcloud, and got NGINX Reverse Proxy Manager working (had to use built-in DB). HTTPS and Asterisk coming next…
