Skip Nextcloud startup checks? They're pretty slow.

[hoellen]

Skip Nextcloud startup checks? They're pretty slow.

[hoellen]

Hello @mhbates,

the startup checks are required for some files to ensure the right permissions.
CHECK_PERMISSIONS skips only the check for the /data folder. If you skip the permission check, the checks are then only done for small folders (like /config, /apps2 etc.).

That should not take very long. Except your hardware is really slow.
Did you recreated the container after changing the variable? Only a restart is not enough:

docker-compose down && docker-compose up -d

Which folder takes you so long to check the permissions?
I hope I could help.

hoellen

[mhbates]

It's about 20-30 minutes total, I haven't timed it exactly. It seemed just as long with CHECK_PERMISSIONS set to 0 - this is the correct value to disable it, right?

And yes, I removed and recreated the container.

The other folders besides data total 300 MB.

[hoellen]

20-30 minutes is pretty long. You can see in the Nextcloud container log which folder is taking so long.

Updating permissions in /FOLDER

Yes setting the variable to 0 is right.
Do you see the following line in your docker log from the Nextcloud container?

WARNING: Skip checking permissions for /data

Or is it:

Updating permissions in /data

Does your storage has a slow IO time?

[mhbates]

Just tested again. With the check disabled, it's actually around 15 minutes. This is the step it's on for most of that time:

Updating permissions in /nextcloud...

Does it also check external storage folders? Are those included in "/nextcloud"?

Also, it looks like the check is actually taxing my boot/OS drive, and not the dedicated Nextcloud drive or the external folders on other drives. Strange.

[hoellen]

External storage should not be checked.
Can you share your docker-compose.yml file? Maybe the volume mounts are wrong?

The docker images and their containers are probably on your boot/OS drive. That could be the reason why it taxes the drive.

[mhbates]

See docker run below. You're saying whatever checks it's doing on the "/nextcloud" folder, those checks are originating from the boot drive? It feels like the actual reading/effort is being done ON the boot drive, which I imagine shouldn't be happening since the majority of the data is on another drive. What would cause it to put that load on the boot drive?

That youtube-dl folder, Drive2 folder, and Drive3 folder are the external storage.

docker run -d --name nextcloud \
       --link db_nextcloud:db_nextcloud \
       --link redis_nextcloud:redis \
       -v /mnt/drive1/nextcloud/data:/data \
       -v /mnt/drive1/nextcloud/config:/config \
       -v /mnt/drive1/nextcloud/apps:/apps2 \
       -v /mnt/drive1/nextcloud/themes:/nextcloud/themes \
       -v /home/$USER/youtube-dl:/youtube-dl \
       -v /mnt/drive2/media:/media \
       -v /mnt/drive3/othermedia:/mnt/drive3/othermedia\
       -e UID=1000 -e GID=1000 \
       -e UPLOAD_MAX_SIZE=10G \
       -e APC_SHM_SIZE=256M \
       -e OPCACHE_MEM_SIZE=256 \
       -e MEMORY_LIMIT=1024M \
       -e CRON_PERIOD=15m \
       -e CRON_MEMORY_LIMIT=2048m \
       -e TZ=America/Los_Angeles \
       -e DB_TYPE=mysql \
       -e DB_NAME=dbname \
       -e DB_USER=dbname \
       -e 'DB_PASSWORD=variouscharacters' \
       -e DB_HOST=db_nextcloud \
	   -e CHECK_PERMISSIONS=0 \
       -p 5005:8888 \
       hoellen/nextcloud:17.0

[hoellen]

The volumes all look right.
The /nextcloud folder from your container is located in the docker root (default: /var/lib/docker).
So when the permission will be changed the change is in /var/lib/docker/overlay2/<hash>/.
You should see a increased load on the disk on which this path is located.
Unfortunately I have no glue why it takes so long in your case.

[mhbates]

Thanks for your help. Could I just mount /nextcloud on the other drive as well?

[hoellen]

No. For that you need to change your docker root directory. Here you can read how to change it.

[mhbates]

It looks like the startup time is now massively reduced, it's just a minute or two now. Not sure what changed, really. I had recently cleared out a bunch of "orphaned" unused docker volumes on the boot drive that had piled up (this was a couple days ago), and also restarted the server today. My guess at this point is that the restart fixed it somehow, since based on logs it looks like Nextcloud still had a long startup time after a container recreation early this morning due to a Watchtower update.

Feel free to close this if you'd like. Hopefully this report helps in some way.

[hoellen]

I'm glad you figured it out (for whatever reason 🙈 ).