AST Configuration Assistance

Hi Mikesisav​ ,

You could try adding the "z" flag:  sudo docker run --rm -it -w /app -v ${PWD}:/app:z --entrypoint /app/src/bin/init_entrypoint.sh python:3.12.6-slim-bookworm --generate-config

lowercase "z"  relabels the volume as shared which lets container to read/execute the script.

uppercase "Z"  handles for private relabeling for stricter isolation.

Then go ahead and try to start the services

Thanks, Jeffrey.

Got something different this time.  If you can think of any other commands to try, I would appreciate it.  

sudo docker run --rm -it -w /app -v ${PWD}:/app:z --entrypoint /app/src/bin/init_entrypoint.sh python:3.12.6-slim-bookworm --generate-config
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "/app/src/bin/init_entrypoint.sh": stat /app/src/bin/init_entrypoint.sh: no such file or directory: unknown

Hi Mikesisav​ 

Can you check your current working directory? It should be in /[your]/[ast]/[path]/application-study-tool
You can run "pwd" for this.

Can you also check your default permissions by running "umask"? If it ends with a 7, new files, by default, will be created with RWX permissions disabled for "other" users (which these containers run under).
(If you are curious about what this command does, see the post, "What is "umask" and how does it work?")

If you post the output of "pwd" and "umask" here, we'll also take a look.

Thanks, @jeff and @jason.  

Update....complete wipe of AST .tarballer and pulled new version from github repo. 

Moved forward on with this command : # Run the configuration generator docker run --rm -it -w /app -v ${PWD}:/app --entrypoint /app/src/bin/init_entrypoint.sh python:3.12.6-slim-bookworm --generate-config

But, having issuers with docker compose up.  Getting permission issuers with /etc/promethus directory and files that does not seem to exist.  

Have a ticket with support but taking advantage of the community here and other support avenues.  

any idea what process builds out /etc/promethus.  see below error: 

prometheus | ts=2025-11-24T19:25:14.744Z caller=main.go:184 level=info msg="Experimental OTLP write receiver enabled" prometheus | ts=2025-11-24T19:25:14.746Z caller=main.go:537 level=error msg="Error loading config (--config.file=/etc/prometheus/prometheus.yml)" file=/etc/prometheus/prometheus.yml err="open /etc/prometheus/prometheus.yml: permission denied" otel-collector-1 | Error: failed to get config: cannot resolve the configuration: cannot retrieve the configuration: unable to read the file file:/etc/otel-collector-config/defaults/bigip-scraper-config.yaml: open /etc/otel-collector-config/defaults/bigip-scraper-config.yaml: permission denied otel-collector-1 | 2025/11/24 19:25:14 collector server run finished with error: failed to get config: cannot resolve the configuration: cannot retrieve the configuration: unable to read the file file:/etc/otel-collector-config/defaults/bigip-scraper-config.yaml: open /etc/otel-collector-config/defaults/bigip-scraper-config.yaml: permission denied

grafana | logger=settings t=2025-11-24T19:25:15.467861683Z level=info msg="Config loaded from" file=/usr/share/grafana/conf/defaults.ini grafana | logger=settings t=2025-11-24T19:25:15.467872603Z level=info msg="Config loaded from" file=/etc/grafana/grafana.ini grafana | logger=settings t=2025-11-24T19:25:15.467876995Z level=info msg="Config overridden from command line" arg="default.paths.data=/var/lib/grafana" grafana | logger=settings t=2025-11-24T19:25:15.467881287Z level=info msg="Config overridden from command line" arg="default.paths.logs=/var/log/grafana" grafana | logger=settings t=2025-11-24T19:25:15.467884836Z level=info msg="Config overridden from command line" arg="default.paths.plugins=/var/lib/grafana/plugins" grafana | logger=settings t=2025-11-24T19:25:15.467888419Z level=info msg="Config overridden from command line" arg="default.paths.provisioning=/etc/grafana/provisioning" grafana | logger=settings t=2025-11-24T19:25:15.467891954Z level=info msg="Config overridden from command line" arg="default.log.mode=console" grafana | logger=settings t=2025-11-24T19:25:15.467896151Z level=info msg="Config overridden from Environment variable" var="GF_PATHS_DATA=/var/lib/grafana" grafana | logger=settings t=2025-11-24T19:25:15.467900698Z level=info msg="Config overridden from Environment variable" var="GF_PATHS_LOGS=/var/l

Thanks and Happy Friday.  

Added /etc - ls -al for transparency.  

Hello Mikesisav​,

First, the /etc in the logs refers to this directory within the container (not the host), so it's OK if we don't see anything related to Prometheus in your host's /etc directory.

Second, can you run "umask" and "ls -l otel-collector-config/defaults/" from your application-study-tool/ directory? It looks like you have permissions issues, but this will confirm, and also give us one possible cause.

thanks, jason.  here go :

[user@f05astpl001 application-study-tool]$ pwd
/nas/home/user/application-study-tool
[user@f05astpl001 application-study-tool]$ umask
0027
[user@f05astpl001 application-study-tool]$ ls -l otel-collector-config/defaults/
ls: cannot access 'otel-collector-config/defaults/': No such file or directory
[user@f05astpl001 application-study-tool]$ 

Thanks, Mikesisav​.

The umask value of 0027 ends with a 7, which will strip away all permissions for user "other". This will continue to happen even if you reinstall AST. To solve this, you need to either change the umask (by running a command like "umask 0022", which removes write permissions from users, "group" and "other", but leaves read and execute permissions intact) or manually add read (and execute, where appropriate) permissions to all files, recursively, in the directory after cloning the repo.

Running the umask command is the cleanest way to overcome this (but would require a fresh clone of the Git repo), but you might not have permissions to run that command. If you don't, or would prefer to preserve the configuration you've already done, you'll need to modify the permissions in your existing repo clone.

Hope that makes sense. Let me know if anything is unclear and, if you run through this, let me know how it goes.

Edited to reflect umask 0022 : 

[user@f05astpl001 application-study-tool]$ umask
0022

Ran sudo docker compose up and still having issues with /etc permissions. 

Also : [user@f05astpl001 application-study-tool]$ ls -l otel-collector-config/defaults/
ls: cannot access 'otel-collector-config/defaults/': No such file or directory

example : Error: failed to get config: cannot resolve the configuration: cannot retrieve the configuration: unable to read the file file:/etc/otel-collector-config/defaults/bigip-scraper-config.yaml: open /etc/otel-collector-config/defaults/bigip-scraper-config.yaml: permission denied
otel-collector-1  | 2025/12/01 16:51:52 collector server run finished with error: failed to get config: cannot resolve the configuration: cannot retrieve the configuration: unable to read the file file:/etc/otel-collector-config/defaults/bigip-scraper-config.yaml: open /etc/otel-collector-config/defaults/bigip-scraper-config.yaml: permission denied

Thanks for your help with this.  

Any idea what I can do next..perhaps this next option?  

If you don't, or would prefer to preserve the configuration you've already done, you'll need to modify the permissions in your existing repo clone

You have a few choices now. With the new umask value, you can re-clone the repo and start over, or you can make everything readable for "other" within the existing repo you have. If you decide to do the latter, the command, "chmod -R o+r .", will do that. (You might need "sudo" before it if your existing user account doesn't have sufficient permissions to change these files.)

On a separate note, I now see that the "ls -l otel-collector-config/defaults/" command you were running should have been "ls -l services/otel_collector/defaults/". That should work better for listing the files in this directory.