Skip to main content

​
Running prowler I get [File: utils.py:15] [Module: utils] CRITICAL: path/redacted: OSError[13]

That is an error related to file descriptors or opened files allowed by your operating system. In macOS Ventura, the default value for the file descriptors is 256. With the following command ulimit -n 1000 you’ll increase that value and solve the issue. If you have a different OS and you are experiencing the same, please increase the value of your file descriptors. You can check it running ulimit -a | grep "file descriptors". This error is also related with a lack of system requirements. To improve performance, Prowler stores information in memory so it may need to be run in a system with more than 1GB of memory. See section Logging for further information or contact us.

​
Common Issues with Docker Compose Installation

​
Problem adding AWS Provider using “Connect assuming IAM Role” in Docker

See GitHub Issue #7745 for more details. When running Prowler App via Docker, you may encounter errors such as Provider not set, AWS assume role error - Unable to locate credentials, or Provider has no secret when trying to add an AWS Provider using the “Connect assuming IAM Role” option. This typically happens because the container does not have access to the necessary AWS credentials or profiles. Workaround:
  • Ensure your AWS credentials and configuration are available to the Docker container. You can do this by mounting your local .aws directory into the container. For example, in your docker-compose.yaml, add the following volume to the relevant services:
volumes:
  - "${HOME}/.aws:/home/prowler/.aws:ro"
This should be added to the api, worker, and worker-beat services.
  • Create or update your ~/.aws/config and ~/.aws/credentials files with the appropriate profiles and roles. For example:
[profile prowler-profile]
role_arn = arn:aws:iam::<account-id>:role/ProwlerScan
source_profile = default
And set the environment variable in your .env file: 
AWS_PROFILE=prowler-profile
  • If you are scanning multiple AWS accounts, you may need to add multiple profiles to your AWS config. Note that this workaround is mainly for local testing; for production or multi-account setups, follow the CloudFormation Template guide and ensure the correct IAM roles and permissions are set up in each account.

​
Scans complete but reports are missing or compliance data is empty (Too many open files error)

When running Prowler App via Docker Compose, you may encounter situations where scans complete successfully but reports are not available for download, compliance data shows as empty, or you see 404 errors when trying to access scan reports. Checking the worker container logs may reveal errors like [Errno 24] Too many open files. This issue occurs because the default file descriptor limits in Docker containers are too low for Prowler’s operations. Solution: Add ulimits configuration to the worker and worker-beat services in your docker-compose.yaml: 
services:
  worker:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    # ... rest of service configuration

  worker-beat:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    # ... rest of service configuration
After making these changes, restart your Docker Compose stack: 
docker compose down
docker compose up -d
We are evaluating adding these values to the default docker-compose.yml to avoid this issue in future releases.

​
API Container Fails to Start with JWT Key Permission Error

See GitHub Issue #8897 for more details. When deploying Prowler via Docker Compose on a fresh installation, the API container may fail to start with permission errors related to JWT RSA key file generation. This issue is commonly observed on Linux systems (Ubuntu, Debian, cloud VMs) and Windows with Docker Desktop, but not typically on macOS. Error Message: Checking the API container logs reveals: 
PermissionError: [Errno 13] Permission denied: '/home/prowler/.config/prowler-api/jwt_private.pem'
Or: 
Token generation failed due to invalid key configuration. Provide valid DJANGO_TOKEN_SIGNING_KEY and DJANGO_TOKEN_VERIFYING_KEY in the environment.
Root Cause: This permission mismatch occurs due to UID (User ID) mapping between the host system and Docker containers:
  • The API container runs as user prowler with UID/GID 1000
  • In environments like WSL2, the host user may have a different UID than the container user
  • Docker creates the mounted volume directory ./_data/api on the host, often with the host user’s UID or root ownership (UID 0)
  • When the application attempts to write JWT key files (jwt_private.pem and jwt_public.pem), the operation fails because the container’s UID 1000 does not have write permissions to the host-owned directory
Solutions: There are two approaches to resolve this issue: Option 1: Fix Volume Ownership (Resolve UID Mapping) Change the ownership of the volume directory to match the container user’s UID (1000): 
# The container user 'prowler' has UID 1000
# This command changes the directory ownership to UID 1000
sudo chown -R 1000:1000 ./_data/api
Then start Docker Compose: 
docker compose up -d
This solution directly addresses the UID mapping mismatch by ensuring the volume directory is owned by the same UID that the container process uses. Option 2: Use Environment Variables (Skip File Storage) Generate JWT RSA keys manually and provide them via environment variables to bypass file-based key storage entirely: 
# Generate RSA keys
openssl genrsa -out jwt_private.pem 4096
openssl rsa -in jwt_private.pem -pubout -out jwt_public.pem

# Extract key content (removes headers/footers and newlines)
PRIVATE_KEY=$(awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' jwt_private.pem)
PUBLIC_KEY=$(awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' jwt_public.pem)
Add the following to the .env file: 
DJANGO_TOKEN_SIGNING_KEY=<content of jwt_private.pem>
DJANGO_TOKEN_VERIFYING_KEY=<content of jwt_public.pem>
When these environment variables are set, the API will use them directly instead of attempting to write key files to the mounted volume.
A fix addressing this permission issue is being evaluated in PR #9953.

​
SAML/OAuth ACS URL Incorrect When Running Behind a Proxy or Load Balancer

See GitHub Issue #9724 for more details. When running Prowler behind a reverse proxy (nginx, Traefik, etc.) or load balancer, the SAML ACS (Assertion Consumer Service) URL or OAuth callback URLs may be incorrectly generated using the internal container hostname (e.g., http://prowler-api:8080/...) instead of your external domain URL (e.g., https://prowler.example.com/...). Root Cause: Next.js environment variables prefixed with NEXT_PUBLIC_ are bundled at build time, not runtime. The pre-built Docker images from Docker Hub (prowlercloud/prowler-ui:stable) are built with default internal URLs. Simply setting NEXT_PUBLIC_API_BASE_URL in your .env file or environment variables and restarting the container will NOT work because these values are already compiled into the JavaScript bundle. Solution: You must rebuild the UI Docker image with your external URL: 
# Clone the repository (if you haven't already)
git clone https://github.com/prowler-cloud/prowler.git
cd prowler/ui

# Build with your external URL as a build argument
docker build \
  --build-arg NEXT_PUBLIC_API_BASE_URL=https://prowler.example.com/api/v1 \
  --build-arg NEXT_PUBLIC_API_DOCS_URL=https://prowler.example.com/api/v1/docs \
  -t prowler-ui-custom:latest \
  --target prod \
  .
Then update your docker-compose.yml to use your custom image instead of the pre-built one: 
services:
  ui:
    image: prowler-ui-custom:latest  # Use your custom-built image
    # ... rest of configuration
The NEXT_PUBLIC_ prefix is a Next.js convention that exposes environment variables to the browser. Since the browser bundle is compiled during docker build, these variables must be provided as build arguments, not runtime environment variables.