This type of permission issue can occur when the directory containing your docker-compose.yaml file, configuration subdirectories (config/), scripts, and other deployment artifacts resides directly on certain shared file systems.
The primary reason is the way in which Docker volume mounts interact with the
permission models of these file systems. Many essential files are mapped from your
deployment directory into the containers (often using relative paths). Shared file
systems frequently have strict permission enforcement based on user/group IDs or use
mechanisms like root_squash (common on NFS).
The user account running processes inside the container (which might be root or a specific non-root user ID defined in the container image) may not have the necessary read/execute permissions on the mapped files according to the rules enforced by the shared file system. This can happen if the container user's UID/GID does not align with the file ownership on the share, or if root access from the container is mapped to a non-privileged user (like nobody) on the share.
Solution: The recommended approach to avoid these permission conflicts is to run the Docker Compose deployment from a local file system on the host machine where Docker is running:
Move or copy your entire HPS deployment directory (the docker-compose-customer/ directory containing docker-compose.yaml, .env, config/, and so on) to a path on a local disk.
Example: Placing the deployment in a directory like /opt/hps or /srv/deployment/ansys-hps on the host's local storage is generally more reliable.
Run your Docker Compose commands from this new location on the local file system.