Artifactory 7.77

JFrog Release Information


Artifactory 7.77 introduces the next generation permission model and your existing permissions are migrated.Permissions

The new model is fully backward compatible with the legacy permissions model.

You might encounter the following known issues during migration.

Cannot Modify Permission

Migration locks the old tables so that no new data is inserted into them.

If an old node tries to perform a change to the old permissions table (via UI/API) during migration, the following error occurs: will get the following error: JFrog migration is running in the background, cannot modify permissions, please wait for the migration to finish


Wait until migration for all nodes is complete.

The error will not be thrown after the migration is complete.

Long Migration Time for Large Customers

A large customer is a customer that has more than 100K permissions.

Migration might take a few minutes for large customers. During migration the JFrog Access service will not communicate with the other internal JFrog services. 

Currently, all internal JFrog services are waiting for 5 minutes for JFrog Access to start. In case JFrog Access service does not respond during this time, they shutdown.


Configure the services to wait for 10 minutes to allow JFrog Access service the time it needs to migrate.

If you are a large customer and not yet started the migration, set the following values in system.yaml.

        bootstrapKeysReadTimeoutSecs: 600
            retries: 600
            retries: 600

    joinTimeoutMins: 10
    pingTimeoutMins: 10

    joinTimeout: 10m

    joinTimeoutMins: 10
    pingTimeoutMins: 10

    joinTimeout: 10m
    pingTimeout: 10m

If you are a large customer and your migration failed since it took a long time, wait until the migration is complete and restart the entire system.

Migration Lock Database Tables Failure

For the migration to work properly, and to avoid data loss, the first step is locking the legacy permissions tables.

The lock is done by creating a trigger that throws an error when a customer tries to manipulate the old permissions tables.

Creating these triggers requires the database user to have special grants. For example, in MySQL/MariaDB, the user has to have SUPER user grants.

If the user doesn't have the proper permissions to create these triggers, the migration will fail.

The migration name is: V7_82_0_1__PermissionsV2DataMigration


  1. Remove the failing migration from the database with the following command.

    DELETE from access_schema_version where version=''

    This allows the migration to run again on the next restart.


    Do not restart at this point!

  2. Choose one of the following solutions.

    • Elevate the DB user permissions so it can create TRIGGERs.

    • If you’re using MySQL or MariaDB, set the flag, SET GLOBAL log_bin_trust_function_creators = 1;, which allows the creation of TRIGGERs and FUNCTIONs.

      You can remove the flag after the migration is complete.

    • Starting Artifactory 7.77.5, you can manually review and apply the TRIGGERs to your database and skip their automatic creation during the migration.

      To skip the triggers creation, set either one of the following properties.

      • Java System Property: jf.access.skip_pv2_legacy_tables_lock=true

      • Environment Variable: JF_ACCESS_SKIP_PV2_LEGACY_TABLES_LOCK=true


      Do not restart the migration and skip the TRIGGERs creation before manually setting the TRIGGERs!

      It can cause a data loss of permissions in the system (if you add/remove/edit permissions while some nodes in your JPD were not upgraded, you will lose these changes).

  3. You are ready to run the migration again.

    Upgrade your nodes to the new version, the migration will succeed.

Issue ID


Fix Version

Additional Information


As a result of changing the Nginx Internal Ports to 8080/8443, the value of X-JFrog-Override-Base-Url was changed. This can lead to redirect issues while access JFrog Artifactory and prevent users from being able to run “Docker Login”.


This issue impacts only Helm Installations with nginx.enabled=trueANDnginx.service.ssloffload=false. For more information, see production incident: Nginx new port setup is broken Issue #1860