Troubleshooting

This troubleshooting chapter explains how to identify and resolve common issues.

The previous examples use simple bind mounts with the “-v” option. For integration and testing, bind mounts are an easy way to get started. But when running native Docker on Linux, be aware that the airlock user inside the container has the UID 1000 by default, which may not match your local user ID.

The UID of the airlock user will “leak” through to your local file system.

Run the following troubleshooting steps, in case you run into problems with file permissions:

ls -l iam/instances/* # You may notice that the owner of the files is "1000" or a user other than your current user
# Use "chown" to change the owner and "chmod" to fix the file permissions
sudo chown -R 1000:0 iam/
# If changing the owner is not enough, fixing the permission modes with "chmod" might be necessary
sudo chmod -R u+rwX iam/

You may also use --user $(id -u) as part of docker run to use your user ID inside the container:

docker run --rm --user $(id -u) -v "$(pwd)/iam:/home/airlock/iam" quay.io/airlock/iam:8.5  # <iam-cli-options>...

Be aware that when copying the configuration files to production, or any other machine or environment, you must change the owner back to “1000:0”:

COPY --chown=1000:0 ./iam/ /home/airlock/iam/

# To fix problems with file permissions, you can add the "--user 0" option to a run command to get temporary root-level access inside the container
docker run --rm --entrypoint /bin/bash -it \
	-v "$(pwd)/iam/:/home/airlock/iam/" \
	--user 0 \
	quay.io/airlock/iam:8.5 \
	-c 'chown -R 1000:0 /home/airlock/iam/'

When running Airlock IAM in Docker/Kubernetes, you may notice an increasing memory usage. If regular Java options for limiting heap and non-heap size do not resolve the issue, consider the following: