The "permission denied" error on the internal

dbt_packages

folder when running

edr report

in Kubernetes is a common issue. This happens because the Elementary CLI (

edr

) uses an internal dbt project located inside the installed Python package directory (e.g.,

/usr/local/lib/python3.8/site-packages/elementary/monitor/dbt_project

). When

edr

runs, it tries to install dbt dependencies in this directory, and if the user running the process doesn't have write permissions, you'll get a permission denied error. How to resolve: - Change permissions on the package directory: You need to ensure that the user running the

edr

command in your container has write access to the Elementary package directory. This can be done in your Dockerfile by adding a command like:

RUN chown -R <your_user> /usr/local/lib/python3.8/site-packages/elementary

Replace

<your_user>

with the user that runs your application in the container. This approach has been confirmed to work by several users in similar Kubernetes and Docker setups [see example](https://slack.com/archives/C02CTC89LAX/p1685408463792899). - Alternative: Use sudo or chmod (if possible): If you have the ability, you can also use:

sudo chmod -R 777 /usr/local/lib/python3.8/site-packages/elementary/monitor/dbt_project

But this is often not allowed in production or secure environments. - Why does this happen? Elementary's internal dbt project is separate from your own dbt project. It needs to install its own dependencies, and by default, it tries to do so in the package directory, which may not be writable by default in many containerized or cloud environments [see explanation](https://slack.com/archives/C02CTC89LAX/p1685408463792899). - If you cannot change permissions: If your security policies prevent you from changing permissions or running as root, you may need to work with your DevOps or security team to find a solution. Some users have reported that even with Dockerfile changes, Kubernetes or cloud policies can override permissions, so coordination with your platform team may be necessary [see discussion](https://slack.com/archives/C02CTC89LAX/p1685408463792899). Summary: You must ensure the user running

edr

has write access to the internal Elementary dbt project directory inside your Python site-packages. This is typically done by adjusting permissions in your Dockerfile after installing the package. If you need more specific guidance for your environment, please provide details about your Dockerfile or Kubernetes setup.

@kapa.ai can I change where the deps are installed instead?

New message text here

The permission denied error on

/.edr

(or similar, e.g.,

/home/airflow/.edr

) occurs because Elementary tries to create a configuration directory in the user's home directory to store things like configuration files and anonymous telemetry IDs. If this directory is not writable (common in containerized or restricted environments), you'll see this error. How to resolve: You can change where Elementary writes its config directory by using the

--config-dir

CLI parameter and pointing it to a writable location. For example:

bash edr report --config-dir /tmp/.edr

This tells Elementary to use

/tmp/.edr

(or any other writable directory) instead of the default location. This approach is recommended if your home directory is not writable due to security or container restrictions. This solution is confirmed in the knowledge sources, where support staff recommend using the

--config-dir

parameter to avoid permission issues with the default

.edr

directory location [see discussion](https://slack.com/archives/C02CTC89LAX/p1686278697336859). If you continue to have issues, ensure the directory you specify actually exists and is writable by the user running the

edr

command.

Even when you set the

DBT_PACKAGES_FOLDER

to a writable location, Elementary's internal dbt project will still attempt to write other files (such as the

target

directory) inside its own package directory (e.g.,

elementary/monitor/dbt_project/target

). If this directory is not writable, you will continue to encounter permission denied errors. This is a known limitation: while you can redirect where dbt packages are installed, dbt will still create the

target

directory and other files inside the internal dbt project directory, which by default resides in the (often read-only) Python site-packages path. The only reliable workaround mentioned in the knowledge sources is to ensure that the user running the

edr

command has write permissions to the internal dbt project directory. This is typically done by changing the permissions or ownership of the directory after installing Elementary in your Dockerfile or container setup:

bash RUN chown -R <your_user> /usr/local/lib/python3.8/site-packages/elementary

or

bash sudo chmod -R 777 /usr/local/lib/python3.8/site-packages/elementary/monitor/dbt_project

If your environment does not allow you to change permissions on this directory (for example, due to strict security policies in Kubernetes or managed environments), there is currently no supported way to fully redirect all writes away from the internal dbt project directory. This limitation is discussed in several threads, and users in similar situations have had to work with their DevOps or security teams to find a solution or consider alternative deployment strategies [see discussion](https://slack.com/archives/C02CTC89LAX/p1685408463792899) [see also](https://slack.com/archives/C02CTC89LAX/p1716798424976069). In summary: Setting

DBT_PACKAGES_FOLDER

helps with dbt package installation, but you must also ensure the internal dbt project directory is writable for Elementary to function correctly. There is currently no CLI flag or environment variable to fully relocate the

target

directory for the internal dbt project.