Question: CAN_INSTALL still there when following migration guide. Does it do any harm?

[hypervtechnics]

The file is still there after following the guide. Is it supposed to work like that? What does this file do? Can I safely remove it?

[joshtrichards]

What guide? Please provide precise reproduction steps as there are numerous ways documented in the README alone.

We don't do any handling of CAN_INSTALL in the Docker image. It's handled by NC Server itself.

Also:

• check your Docker logs for the app container to see if any errors/hints were provided during deployment
• If you're using bind mounts, confirm permissions of the config/ folder

[hypervtechnics]

Hi, thanks for the reply.

As a disclaimer: I am not deep into the implementation details of nextcloud and the ecosystem.

When dealing with other PHP based apps I often read on the documentation that files like CAN_INSTALL have to be deleted on running instances. Often they are used as an indicator for web based installers whether the installer is allowed to operate. Often this is serious security issue and some apps even remove installer.php of such applications after completing the installation.

Now I got nervous as after migrating my nextcloud instance from bare metal to a docker setup based on this image, such a file was in the config directory. I followed the migration steps at the end of the readme of this repo. While migrating the regular installation process is circumvented. At least the guide does not mention to execute the installation like you would on a completly new setup. When doing a clean install the file in question is deleted, so this mainly affects migrations.

Reference to guide: https://github.com/nextcloud/docker?tab=readme-ov-file#migrating-an-existing-installation

Don't get me wrong: The instance is running fine and the migration was successful in that regard. I was just nervous because of my experience with other applications and opened this issue to ensure.

A bit more context: I checked the config.php and there is a setting installed => true. Tho I read in some other issues that this is not part of the official config schema. I checked using the advisor on the general page of the administration section in the web interface and it did not complain about the file being there. For now I just deleted it, as I was paranoid about opening some obscure way to attack the instance.

[joshtrichards]

I followed the migration steps at the end of the readme of this repo. While migrating the regular installation process is circumvented. At least the guide does not mention to execute the installation like you would on a completly new setup.

I just saw this part and I think I know what happened in your case. The migration steps do (typically) still involve running and doing a base installation. The first step of the migration README says:

1. Define your whole Nextcloud infrastructure in a docker-compose file and run it with docker-compose up -d to get the base installation, volumes and database. Work from there.

I'm guessing maybe you skipped the run/launch part that gets you a base installation. You jumped straight to the db restore perhaps?

That's probably fine, but it would explain why the file was still around.

[hypervtechnics]

Hi,

I did two rounds for the migration.

In the first round I just ran docker compose up and completed the browser based installation steps. This was to verify if my container setup/compose file is capable of operating a working nextcloud installation. This way I can verify whether I did a mistake/there was an error during migration, when then migrated instance would not have been fully functional. I also copied the config dir for reference to appropiatly migrate/split my config.php into the new structure and maybe remove some settings which have been default 4 years ago when I setup the bare metal instance. I then reset everything - deleted the volumes, networks, containers, etc.

In the second round I indeed skipped the browser based installation steps, as it was not explicitly explicitly mentioned in step 1. It only mentioned doing a docker compose up. So I went from there. My expectation has been, that the application should fully rely on the migrated database, config and data dir and that if the migration was successful it should detect that no setup is required as everything is already there.

So yeah, that explains why the file was still there 🙂 I guess: case closed 🚀