Removing Nextcloud steps seem to be incomplete.

[stephenmkbrady]

System: Debian 9 linode vm Description: I tried to remove and reinstall with this playbook when I was debugging an issue that I was seeing with certbot docker.

Note: The certbot issue is unrelated to this current issue, and was in my DNS configuration, as I forgot to add www A record.

When I fixed that DNS issue, I tried reinstalling from scratch, I ran into some issues with the database.

Steps:

1. I followed the uninstall steps

• This didn't get rid of the containers on Debian: ansible-playbook nextdocker.yml -e state=absent So I run docker stop $(docker ps -a -q) && docker rm $(docker ps -a -q) && rm -rf /opt/nextcloud/

2. I did find and grep searches to make sure I removed files related to "nextcloud". I noticed I still had users and groups, which I thought is fine as I'll need them again.
3. I reinstalled, only changing the ssl_cert_email and nextcloud_server_fqdn and all the passwords were blank because I wanted random generated. Observed: During install I get the error:

fatal: [localhost]: FAILED! => changed=true 
  cmd: |-
    docker exec --user www-data nextcloud php occ  maintenance:install  --database pgsql --database-host nextcloud-db --database-name nextcloud  --database-table-prefix oc_ --database-user nextcloud --database-pass xxx  --admin-user admin --admin-pass xxx --data-dir /var/nc-data
  delta: '0:00:00.345130'
  end: '2019-12-25 10:02:10.559402'
  msg: non-zero return code
  rc: 1
  start: '2019-12-25 10:02:10.214272'
  stderr: ''
  stderr_lines: <omitted>
  stdout: |-
    Error while trying to create admin user: Failed to connect to the database: An exception occurred in driver: SQLSTATE[08006] [7] FATAL:  password authentication failed for user "nextcloud"
     ->
  stdout_lines: <omitted>

Also the web interface at https://nextcloud.<my-domain.tld> is up but tells me:

Error It looks like you are trying to reinstall your Nextcloud. However the file CAN_INSTALL is missing from your config directory. Please create the file CAN_INSTALL in your config folder to continue.

I think the root cause is that I needed to remove the users and passwords before installing again as when I rebuilt my vm and installed with same settings it works perfectly and the only things left on the previous debian9 vm relating to nextcloud config were the username and passwords. I didn't look too far into where the playbook was getting the passwords or if it was overwriting them.

[ReinerNippes]

sorry. i have to fix this. since i changed the database volume from /opt/nextcloud/database to nextcloud-database-vol it is not removed anymore when state=absent.

there are two scripts to remove docker items from your server: https://github.com/ReinerNippes/nextcloud_on_docker/tree/master/scripts

or you simply run docker volume rm $(docker volume ls -q) to remove the database volumes.

[james-cook]

To re-install the "complete system" - I did the "same" as above

• ./nextdocker.yml -e state=absent
• . scripts/remove_all_container.sh
• . scripts/remove_all_docker_stuff.sh

No other steps were taken. I restarted the install with

• ./nextdocker.yml

There was a reported problem - a timeout waiting on the nextcloud-db.

TASK [docker_container : wait for nextcloud-db to become ready] ************************************************************************************************************
Friday 17 January 2020  16:03:33 +0000 (0:00:01.250)       0:01:01.813 ********
fatal: [localhost]: FAILED! => changed=false
  elapsed: 30
  msg: Timeout when waiting for 172.21.0.4:3306

So I ran the playbook again, this time there were no problems. Everything comes up as expected in my setup: portainer, traefik etc. BUT nextcloud itself does not.

Instead I get a 500 error in the browser. Drilling down it seems there is a db problem. i.e. I try to launch a simple occ -help command in the nextcloud shell - and get:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'nextcloud.oc_appconfig' doesn't exist in /var/www/html/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:88
Stack trace:
#0 /var/www/html/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php(88): PDO->query('SELECT * FROM `...')
#1 /var/www/html/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(908): Doctrine\DBAL\Driver\PDOConnection->query('SELECT * FROM `...')
#2 /var/www/html/lib/private/DB/Connection.php(195): Doctrine\DBAL\Connection->executeQuery('SELECT * FROM `...', Array, Array, NULL)

UPDATE: if you see this error, you need to move or delete the file at /var/www/html/config/config.php before rebuilding (this is because the database instanceid changes - interestingly the database contents are persisted across this rebuild).

I do note that in the docker nextcloud shell I can still see e.g. apps I added to the original installation in the apps directory. So, somehow despite deleting volumes some file data is persisted(?). I think I can also see the results of dockerfile makes I added to playbook (nextcloud image) - e,g, lib*.so files etc, in directories such as /usr/lib - but I can't be 100% these weren't already present... Is this the expected behaviour?

In this context of removing the initial nextcloud, what is the best approach to running the playbook whilst:

1. preserving user changes to nextcloud and
2. flushing user changes to nextcloud (a complete fresh start)

UPDATE: it always helps to read the README ;).

Your data won't be deleted. You have to do this manually by executing the following.

rm -rf {{ nextcloud_base_dir }}

[ghost]

Hey @james-cook I had the exact same problems you were experiencing. Following your steps helped fix the issue for me, I have finally got a working deployment 👍

EDIT: Not sure whats going on, but logging in and out of the nextcloud instance is awfully slow.

EDIT2: Looks like the slowdown could be due to the brute force option being enabled. Doing some quick research.

[ghost]

@james-cook When the playbook again I believe a new password is generated for the database but it created using a previously generated one which is now lost. Therefore, you cannot access the database.