Migrate docker based deployment to other machine

Avatar
R Voorn
Created

We recently deployed a Youtrack container on a machine, but due to reasons, this deployment needs to be moved to another machine. The docker compose file on the old machine had 4 bind mounts for: data, conf, logs and backup folders inside the docker container to the local host. We copied the docker compose file (which has the same bindings) and also copied the data folders to the new machines on the same location,. The new docker compose file manages to successfully start the docker container, but we cannot log in. Since we have not used LDAP and created the users manually in Youtrack, I would expect the users to be in the database that was moved by moving the bound folders to the new machine. Can anyone tell me why the users on the old machine cannot log into the new deployment? Is this a security measure I am not aware of? In the logs, I cannot find anything that might explain why it does not work, except the log line:

youtrack-1  |  01 Jun 2026 10:26:20,543 INFO  [LoginHandlerImpl    ] [qtp2033260624-77    ] [99-581b-6c80-8718-c84d221483bf] [10.0.100.15] Authentication of [username: pim, serviceId: 1adf970c-8645-4837-806d-b1699a302aa5] against Hub module failed: Bad credentials
 

This does not explain anything except logs that login had failed. We are absolutely certain that the credentials we use are correct, because they work on the old machine.

Votes

0

Share

1 comment
Avatar
Stanislav Katsion
Created

Hi! 
Stan from YouTrack Support here.

The "Bad credentials" line is a deliberately generic message. YouTrack logs the exact same error whether a password is wrong or the account simply isn't found in the database the running instance is using. Since none of your users can log in, and account passwords are stored entirely inside the database (nothing about them depends on the host or the conf folder), this points to the new instance not actually running on the database you copied over, rather than to a credentials problem.

A quick way to confirm: on the first startup of the new machine, were you taken through the setup wizard (entering a license, creating an admin account)?

The two most common reasons a copied data directory doesn't load:

  • File ownership. YouTrack runs inside the container as user 13001. If the copied files are owned by root (the default when copying as root), the container can't read them. Make sure the copied directories and their contents are owned by 13001:13001.
  • The source was still running during the copy. Copying a live database produces an inconsistent snapshot. The old instance needs to be stopped before its data directory is copied.

Rather than copying the live data directory, the supported migration path is to restore from a backup:

  • On the old instance, create a backup (or use the latest file from the backups directory).
  • On the new machine, start a fresh YouTrack and select that backup file as the Upgrade Source during setup.

The full steps are here: Restore a YouTrack Installation. Note that the backup file also needs to be readable by user 13001:13001, as described in the guide.

If you've confirmed the ownership and the instance still won't accept logins, please share an archive of the entire logs directory. You can upload it to uploads.youtrack.cloud (only our team can download the uploaded files), and send the upload ID to us in a support ticket. 

Looking forward to hearing back from you!

0

Please sign in to leave a comment.