Docker: web root html dir is left half-empty on intializing the container.

[ukos-git]

I'm setting up a new docker app with k8 and /var/www/html on NFS mounts.

I don't know why, but sometimes some directories like lib/ are not copied to the web root, yielding in an error like this on web, occ and status.php calls.:

Warning: require_once(/var/www/html/lib/versioncheck.php): failed to open stream: No such file or directory in /var/www/html/index.php on line 36

Fatal error: require_once(): Failed opening required '/var/www/html/lib/versioncheck.php' (include_path='.:/usr/local/lib/php') in /var/www/html/index.php on line 36

and in fact it is not there:

root@nextcloud:/var/www/html# ls /usr/src/nextcloud/
3rdparty  COPYING  config       core      custom_apps  index.html  lib  ocm-provider  ocs-provider  remote.php  robots.txt  status.php  version.php
AUTHORS   apps     console.php  cron.php  data         index.php   occ  ocs           public.php    resources   settings    themes
root@nextcloud:/var/www/html# ls /var/www/html/
3rdparty  AUTHORS  COPYING  console.php  cron.php  index.html  index.php  occ  public.php  remote.php  robots.txt  status.php  version.php
root@nextcloud:/var/www/html#

I could copy the missing files but I'm not sure what it causes. The directory has full (777) permissions. Here is a list of files that differ between /var/www/html and /usr/src/nextcloud:

 3rdparty
 AUTHORS
 COPYING
+apps
+config
 console.php
+core
 cron.php
+custom_apps
+data
 index.html
 index.php
-ls1
+lib
 occ
+ocm-provider
+ocs
+ocs-provider
 public.php
 remote.php
+resources
 robots.txt
+settings
 status.php
+themes
 version.php

Installation is done with empty directories.

I think the relevant line are the rsync lines here:

    rsync $rsync_options --delete --exclude /config/ --exclude /data/ --exclude /custom_apps/ --exclude /themes/ /usr/src/nextcloud/ /var/www/html/

    for dir in config data custom_apps themes; do
        if [ ! -d "/var/www/html/$dir" ] || directory_empty "/var/www/html/$dir"; then
            rsync $rsync_options --include "/$dir/" --exclude '/*' /usr/src/nextcloud/ /var/www/html/
        fi
done

any ideas?
related: https://github.com/nextcloud/docker/issues/251

EDIT:
I tried with and without setting NEXTCLOUD_DATA_DIR because I did not see where this env is taken into account here.

Temporary fix: As I am initializing the web root, I skipped the exclude parameters like this:

rsync -rlDogv --chown www-data:root --delete /usr/src/nextcloud/ /var/www/html/

NOTE: could also be a timeout for the rsync.

[ukos-git]

to know if init succeeded we could add

touch /var/www/html/notInitialized
rsync
rm -f /var/www/html/notInitialized

I would prefer something like that. I think I have seen something like that for the mariadb container.

[LTangaF]

set -e is present, so a failure of rsync ought to have caused entrypoint.sh to fail (unless rsync is just not failing when it doesn't complete).

I'm also running into this, not with an NFS mount, but with bind mounts (intended to be connected to NFS on the host, but presently tested with a local directory) of the data and config directories.

BTW, @ukos-git, the NEXTCLOUD_DATA_DIR is picked up by /var/www/html/config/autoconfig.php on first access (and then I think removed after config.php is created).

I'm probably going to have to just give up trying to fix this unless I just override entrypoint.sh and have it run rsync more than once.

[Geraldf]

for some reason I have the same issue. Installing a fresh nextcloud 14 wiht dockercompose.
I do get this error
Fatal error: require_once(): Failed opening required '/var/www/html/lib/versioncheck.php' (include_path='.:/usr/local/lib/php') in /var/www/html/index.php on line 36

Looking at /var/www/html/ there is no lib folder at all.

docker-compose.yaml

services:
nextcloud:
image: nextcloud
container_name: nextcloud
ports:
- 8085:80
links:
- db
volumes:
- /media/synology/docker/nextcloud/var_www_html:/var/www/html
- /media/synology/docker/nextcloud/data:/var/www/html/data
- /media/synology/docker/nextcloud/themes:/var/www/html/themes/
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
restart: always
environment:
VIRTUAL_HOST: ${DOMAINS}
networks:
- webproxy

[cpeetersburg]

Could this also be related to #567?

[LTangaF]

It's been awhile for me and I had to go look back at what I did to get mine working. I ended up creating my own Dockerfile and entrypoint.sh

[digitalap3]

I was having rsync issues on first run installation and the problem ended up being I was using my 'old' nextcloud image 15.0.0.1 as 'latest'. I changed the tag, downloaded the current image using the latest tag, and all is well.

[ukos-git]

@digitalap3 Can you point me to the relevant changes in the entrypoint.sh. If there has anything happened that closes this issue I woul appreciate it.

[digitalap3]

Sorry I missed this in my email. I'll try to duplicate and see the error message. Should be easy to duplicate using an older nextcloud version.

[ukos-git]

I took a quick look at the 15.0 Dockerfile. As far as I see it, there haven't been any changes.

The problem is that "non-init"-containers usually time out at rsync during initialization. To check if the rsync finished successfully, we would need something like the following:

if [ ! -e uninitialized ]; then
    touch uninitialized

https://github.com/nextcloud/docker/blob/1091814e9b06c8a66d0e3583bb12c591434aeccb/15.0/apache/entrypoint.sh#L47-L54

    rm uninitialized
fi

If you try it out with a fresh container anyway, could you please add the above lines and add a PR if it worked? - I think that would be highly appreciated by any new users because this error is probably encountered primarily by first-time users that want to have an easy-to-use docker container.

[digitalap3]

@ukos-git I should be able to this evening. I did keep the image so it won't be a problem. To be clear though the "problem" (feature not a bug?) is the docker will use an old image and keep the tag as latest instead of downloading the newer image, which led to rsync pulling files meant for a newer version of nextcloud and then exiting out and throwing an error - hence the half filled directories. That's why changing the tag of my docker image from latest to 15.0.0.1 and then pulling the image tagged latest solved the problem.

So the problem isn't nextcloud as much as it is understanding how docker uses and tags images.

I did see reference to version checking in the entrypoint script though so how nextcloud handles that error may be a solution, like throwing a message that tells the user they need to update their docker image.

[ukos-git]

That is a related problem that could get fixed all together with this issue.

The main issue in this thread, though, is with a fresh docker install. No old data. Just a timeout on rsync.

Dropping the rsync would probably avoid all issues at once. Nextcloud is not very docker friendly.

[digitalap3]

Yes but I assumed I was using a fresh install with the latest tag not realizing it was an older version because of the way docker works.

Going back I see your setup is different however if you had an old image and didn't refresh your "latest" tag it could have been the source of your error. Even though it wasn't the two could be related and mine might give some insight. I'll spin up that old image and see what the exact error message is later this evening

[digitalap3]

Dropping the rsync would probably avoid all issues at once. Nextcloud is not very docker friendly.

Would git work better?

[ukos-git]

A lot of maybes. It could definitely be the case that this was the error and not a timeout on rsync. We will never know for sure but you got a point.

Regarding the rsync issue:

Why not keep all static, version based files in /var/www and have mountpoints for data, config, db in one place so that you only need to persist your own data and not the whol nextcloud instance.

That would be how i.e. seafile handles it and it is much more user friendly. You will also probably avoid a lot of chown commands, as www-data or mysql will write their own files and they automatically belong to them.

Another important feature would be that data in the docker container will always be with proper hashes. Restart the container and you are always back at the default state of the image.

[digitalap3]

My error message is in fact different from yours. This was run with only the nextcloud instance. I think my confusion came because I was initially running this in a docker-compose file so the apache server started up fine and then the errors were thrown when I tried to do the first login, versus just running the nextcloud instance as a container with docker run which gave me the error below right away.

Initializing nextcloud 15.0.0.10 ...
rsync: read errors mapping "/usr/src/nextcloud/core/l10n/nl.json": Input/output error (5)
rsync: read errors mapping "/usr/src/nextcloud/core/l10n/nl.json": Input/output error (5)
ERROR: core/l10n/nl.json failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]

[tilosp]

Why not keep all _static_, version based files in /var/www and have mountpoints for data, config, db in one place so that you only need to persist your own data and not the whol nextcloud instance.

The main problem with this approach is php-fpm. Because a web server in a different container needs to access the static files.

But this problem can probably be fixed by copying the version.php file over last.