-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remote instance created with create_cold_standby.sh can not start due to external volumes #5970
Comments
This is kind of "works as designed": https://community.mailcow.email/d/2126-backup-restore/2 (unfortunately in German) Thats why I migrated my Mailcow instance using the normal restore procedure. |
Thanks @mrclschstr for the link. This is disappointing in 2 ways: I would have gone for the restore option too, but the cold standby option explicitly mentions that it is suitable for moving to a different mail server. That's misleading then. What's also disappointing, that the community platform doesn't provide that search result, even when I searched for the error message that the reporter used. I wonder how I should best recover from this scenario now. |
@jurgenhaas I'm curious about what has happened here. I followed you on Mastodon if you need someone to rubber duck this. Both how you can recover and what we can do to prevent similar issues in the future with respect to documentation and what not. Note though that I'm a mailcow beginner myself. |
It's actually ‘only’ a cosmetic problem and, as far as I know, the functionality is not restricted. But I can absolutely understand that the warnings are annoying, which is why I chose a different way to migrate my mailcow instance. Idea for a solution on an already migrated system: Theoretically, it should be enough to make a backup of the Mailcow instance, delete everything on the system and then perform a restore. |
@mrclschstr well, the warnings are gone since I prefixed all the volumes with the project name and declared them external. And yes, functionality is not broken. However, my concern is about the next update. My changes to So. maybe a rest is the best option indeed. Let me think about it. |
Turns out, the update script is smart enough to keep my local changes, so I don't have to reset. |
It is... you must do something wrong then, we use it on daily basis! The warning you get is only a warning. Please do not change anything docker says you should as it could break other things. |
THIS IS A AUTOMATED MESSAGE! It seems your issue is not a bug. You can get support either by:
This issue will be closed. If you think your reported issue is not a support case feel free to comment above and if so the issue will reopened. |
OK, I've reverted the changes and live with the warnings. Thanks @DerLinkman for the hint. It's a bit worrysome and I hope docker is not going to change its mind eventually and turn this from warning into error. Maybe an update to the documentation would be helpful to let other users know about this? |
I did not saw this to be necessary but yeah, why not. |
If they do we adjust our script then. But i don't think so. |
This is related to mailcow#5970 and https://community.mailcow.email/d/2126-backup-restore/2 It adds `docker compose create` to the script which gets executed directly after the sync of the mailcow-dockerized directory. This way the Docker daemon on the remote side creates everything and we get rid of the warning "volume "XYZ" already exists but was not created by Docker Compose. Use `external: true` to use an existing volume" This is helpful if you use the create-cold-standby.sh script to migrate your mailcow installation to another server and don't want to get those warnings after migration.
This is related to #5970 and https://community.mailcow.email/d/2126-backup-restore/2 It adds `docker compose create` to the script which gets executed directly after the sync of the mailcow-dockerized directory. This way the Docker daemon on the remote side creates everything and we get rid of the warning "volume "XYZ" already exists but was not created by Docker Compose. Use `external: true` to use an existing volume" This is helpful if you use the create-cold-standby.sh script to migrate your mailcow installation to another server and don't want to get those warnings after migration. Co-authored-by: Niklas Meyer <[email protected]>
Contribution guidelines
I've found a bug and checked that ...
Description
When we added
external: true
to all volumes indocker-composer.yml
anddocker-composer.override.yml
as the error message suggests, then the volumes can not be found. Validation error of docker compose states:We had to prefix all references to volumes with
mailcowdockerized_
and all works like a charm.But that modification of the yaml files doesn't persist updates. So, that should be fixed otherwise, but we couldn't find anything helpful.
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
x86
Operating System:
Ubuntu 22.04 LTS
Server/VM specifications:
8 Cores, 32 GB RAM
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
n/a
Docker version:
27.1.1
docker-compose version or docker compose version:
2.27.3
mailcow version:
2024-06c
Reverse proxy:
n/a
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check:
The text was updated successfully, but these errors were encountered: