Need help with other JFrog products?
docker ps command lists containers in your system.
Artifactory logs are stored in the Artifactory container under
If you ran the container with a mounted volume for Artifactory data (
/var/opt/jfrog/artifactory/), you can also access the logs locally on your host.
An easy way to see the logged output of a running container is through the
docker logs command
This will output all of the container's STDOUT and STDERR to the screen both for running and stopped containers.
Connect to a Running Container
You can connect to a running container's file system and open an interactive command prompt in the container with the
docker exec command
This will open a command prompt in the running Artifactory container, logging you in as root and placing you in the / directory.
Run an Alternate Entrypoint
There are cases where you want to run the container, but not start up Artifactory. To do this, you need to override the configured entrypoint script using
docker run --entrypoint=bash
This will run the container, presenting you with a prompt in the container, but without executing the
You can then make changes to the container configuration execute
/entrypoint-artifactory.sh to start up Artifactory in your container.
Installing Artifactory HA
Please refer to Troubleshooting HA.
Access Tokens or Access Service
During startup, Artifactory fails to start and an error is thrown:
java.lang.IllegalStateException: Provided private key and latest private key fingerprints mismatch.
Artifactory tries to validate and compare access keys' fingerprint that reside on Artifactory's database and the local file system. If the keys do not match, the exception above will be thrown along with the mismatching fingerprint IDs.
This could occur during an attempted upgrade/installation of Artifactory.
Follow the steps below to make sure that all instances in your circle of trust have the same private key and root certificate:
Key rotation will invalidate any issued access tokens
The procedure below will create new key pairs which in turn will invalidate any existing Access Tokens.
|Symptoms||Authentication with an access token doesn't work with an error that says "Token validation failed".|
|Cause||The implementation of access tokens was changed in Artifactory 5.4. The change is backwards compatible, so tokens created with earlier versions of Artifactory can be authenticated in the new version, however the reverse is not true. Tokens created in versions 5.4 or later cannot be authenticated by versions earlier than 5.4.|
|Resolution||Either upgrade your older Artifactory instances, or make sure you only create access tokens with the older instances|
Recovering from Error: An incompatible index has been found for the Artifactory ‘node_props’ database table
If you are using PostgreSQL and see this message in the Artifactory UI, it is most likely that you have upgraded your Artifactory version to 6.5.0 or above and experienced database conversion that failed to convert indexes for the 'node_props' table. This may be due to certain property values with a length that exceeds the allowed limit of 2400 characters. These long property values are usually a result of internal Artifactory procedures such as package indexing that tag artifact metadata, such as a readme, as properties.
To fix the index, is it mandatory to trim the property values exceeding the maximum allowed limit. Artifactory will not automatically fix and trim the property values as they could be valuable to you. For this reason, we provide the following two REST API's:
Returns response of invalid properties, if any exist.
Trims the invalid properties, if any exist, to the maximum allowed length and run the index conversion.
Setting the dry run command dry= 0 or 1
Setting the parameter to '1' will perform a dry run, whereas setting it to '0' will actually run the command.