issue when renaming the nextcloud volume in docker compose file

[leolivier]

Hi For some unknown reason, the .htaccess file in /var/www/html became unreadable with "bad message" errors I'm using docker compose and /var/www/html was mounted on a temporary volume named nextcloud like that:

volumes:
  nextcloud:

services:
  nextcloud:
...
    volumes:
      - nextcloud:/var/www/html
...

It prevented nextcloud to restart, so I removed the container and tried to remove the volume nextcloud_nextcloud too but it failed as .htaccess was not removable. So finally I just changed nextcloud to nextcloud2 in the docker file like that:

volumes:
  nextcloud2:

services:
  nextcloud:
...
    volumes:
      - nextcloud2:/var/www/html
...```
and restarted nextcloud.
It looks like in the situation, the /entrypoint.sh detects that nextcloud is not installed and tries to reinstall everything including starting the command `occ maintenance:install` but nextcloud is already installed actually!
So, maintenance:install command does not exist anymore, a lot of errors (10 tries) and then nextcloud finally restarted but some applications have disappeared in between (eg mail) and I had to reinstall them.

So, maybe, such a simple action as renaming a volume in the docker compose file should not lead to this situation?

[joshtrichards]

I had some trouble following your report, but let's see if we can get this sorted out a bit.

Unfortunately it seems that a smaller issue (whatever happened to your .htaccess file) may have turned into a larger issue for you.

I'm not sure what you mean by "temporary" volume: your named volume nextcloud containing /var/www/html would have been vital as it would contain all your data (!) and the current iteration of NC installed within configured container "nextcloud".

It sounds like you created a new named volume called nextcloud2 on Docker and referenced it from your existing container (in-place of the previous volume)? That would have effectively been starting from scratch!

You can't simply "rename" a volume like that - but that isn't a nextcloud issue so much as how Docker functions: https://docs.docker.com/storage/volumes/

You say you lost your apps, but what about your data (files/photos/etc)? They should have been lost too unless I'm misunderstanding the steps you went through.

[leolivier]

First of all, thanks for looking at my issue @joshtrichards Maybe my post was a bit misleading as I did not mention that /var/www/html/data and config were mounted as "persistant" volumes on "named" directories:

• /docker/nextcloud/config:/var/www/html/config
• /docker/nextcloud/apps:/var/www/html/apps
• /hdd/nextcloud:/var/www/html/data This is why I'm saying nextcloud volume was temporary which I admit is a wrong term but I meant I didn't care of its content which could be regenerated from scratch. Second point, ok, I can't change nextcloud to nextcloud2 as it recreates nextcloud from scratch but then why "occ maintenance:install" is not working? There is something illogic here as this command is removed once nextcloud is installed only, so either it is already installed (although I changed the volume name) and we should not run the command or it is not installed yet and the command should still exist. To answer your question on how I did the change and maybe reproduce it, I just stopped the container (docker compose down) then changed nextcloud to nextcloud2 in the docker-compose.yml file and restarted everything (docker compose up -d) Maybe that at the end, the issue is just that I thought my apps were stored in the "named directories" volumes and it was wrong?

[martadinata666]

original

  volumes:
    - /docker/nextcloud/config:/var/www/html/config
    - /docker/nextcloud/apps:/var/www/html/apps
    - /hdd/nextcloud:/var/www/html/data

nextcloud2

  volumes:
    - /docker/nextcloud/config:/var/www/html/config
    - /docker/nextcloud/apps:/var/www/html/apps
    - nextcloud2:/var/www/html/data

I assume something like that? it is better that you attach all volumes configuration. What mean empty by the startup script is `/var/www/html` is empty by any means `no subfolder, no hidden files`.

There are 2 place apps stored /var/www/html/apps and /var/www/html/custom_apps usually third-party apps are placed in /var/www/html/custom_apps path.

[leolivier]

Actually no, strictly only renaming nextcloud in nextcloud2, so Before:

volumes:
    - /docker/nextcloud/config:/var/www/html/config
    - /docker/nextcloud/apps:/var/www/html/apps
    - /hdd/nextcloud:/var/www/html/data
    - nextcloud:/var/www/html

After

  volumes:
    - /docker/nextcloud/config:/var/www/html/config
    - /docker/nextcloud/apps:/var/www/html/apps
    - /hdd/nextcloud:/var/www/html/data
    - nextcloud2:/var/www/html

So for me, except the mount points of volumes inside /var/www/html, it should be empty. And if it's not due to the mount points, this should not work either for a brand new installation with that kind of config. I didn't check for custom_apps, why maybe my apps disappeared, I get that. Nevertheless, the "occ maintenance:install" issue remains...

[martadinata666]

Actually no, strictly only renaming nextcloud in nextcloud2, so Before: volumes: - /docker/nextcloud/config:/var/www/html/config - /docker/nextcloud/apps:/var/www/html/apps - /hdd/nextcloud:/var/www/html/data - nextcloud:/var/www/html

After

volumes: - /docker/nextcloud/config:/var/www/html/config - /docker/nextcloud/apps:/var/www/html/apps - /hdd/nextcloud:/var/www/html/data - nextcloud2:/var/www/html

So for me, except the mount points of volumes inside /var/www/html, it should be empty. And if it's not due to the mount points, this should not work either for a brand new installation with that kind of config. I didn't check for custom_apps, why maybe my apps disappeared, I get that. Nevertheless, the "occ maintenance:install" issue remains...

Still what mean empty by the startup script is /var/www/html is empty by any means no subfolder, no hidden files. The nextcloud2 mount still place three subfolder inside /var/www/html, so essentially /var/www/html/config and the friends still inside /var/www/html.

Edit: and occ detect the config already there, os it won't continue. Technically your config and data intact, but the web missing.

[leolivier]

I get your point @martadinata666 but I have to disagree with that interpretation : let's forget my own issue for renaming to focus on brand new install of nextcloud.

The setup I am using, specifically storing user data in a well known place and not in the standard docker repo seems very reasonable to me, even in a brand new installation and will result in an error with the user data totally empty. So empty definition should at least test that 1rst level directory are empty and then consider /var/www/html as empty in this case... Also, I don't know if this is easy to do, but in case of reinstall, we should either re enable the maintenance:install command or not run it

[joshtrichards]

I'm still not really following what the supposed bug is. You deleted your primary persistent volume (the one containing /var/www/data and created a new volume in its replace. What occurred sounds like expected behavior:

https://github.com/nextcloud/docker?tab=readme-ov-file#persistent-data

https://github.com/nextcloud/docker?tab=readme-ov-file#additional-volumes

The setup I am using, specifically storing user data in a well known place and not in the standard docker repo seems very reasonable to me, even in a brand new installation and will result in an error with the user data totally empty.

I still don't follow. The situation you encountered is because you effectively deleted one of your data volumes.

Perhaps the misunderstanding here is you're viewing /var/www/html/ as not being part of your "data", but in this Docker image that folder is supposed to be kept as persistent. It is data. It's important.

The underlying volume type doesn't matter nor does it matter if you use more granular additional volumes for the folders located under it (as described at https://github.com/nextcloud/docker?tab=readme-ov-file#additional-volumes

Can you point out where the behavior does not match what is documented?