File Permissions Errors When Installing F5 Application Study Tool? Here’s Why.

F5 Application Study Tool is a powerful utility for monitoring and observing your BIG-IP ecosystem. It provides valuable insights into the performance of your BIG-IPs, the applications it delivers, potential threats, and traffic patterns.

In my work with my own customers and those of my colleagues, we have sometimes run into permissions errors when initially launching the tool post-installation. This generally prevents the tool from working correctly and, in some cases, from running at all. I tend to see this more in RHEL installations, but the problem can occur with any modern Linux distribution.
In this blog, I go through the most common causes, the underlying reasons, and how to fix it.

Signs that You Have a File Permissions Issue

These issues can appear as empty dashboard panels in Grafana, dashboards with errors in each panel (pink squares with white warning triangles, as seen in the image below), or the Grafana dashboard not loading at all.
This image shows the Grafana dashboard with errors in each panel.

When diving deeper, we see at least one of the three containers are down or continuously restarting. In the below example, the Prometheus container is continuously restarting: 

ubuntu@ubuntu:~$ docker ps 
CONTAINER ID   IMAGE                                     COMMAND                  CREATED         STATUS                          PORTS                                       NAMES 
59a5e474ce36   prom/prometheus                           "/bin/prometheus --c…"   2 minutes ago   Restarting (2) 18 seconds ago                                               prometheus 
c494909b8317   grafana/grafana                           "/run.sh"                2 minutes ago   Up 2 minutes                    0.0.0.0:3000->3000/tcp, :::3000->3000/tcp   grafana 
eb3d25ff00b3   ghcr.io/f5devcentral/application-stu...   "/otelcol-custom --c…"   2 minutes ago   Up 2 minutes                    4317/tcp, 55679-55680/tcp                   application-study-tool_otel-collector_1

 

A look at the container’s logs shows a file permissions error:

ubuntu@ubuntu:~$ docker logs 59a5e474ce36
ts=2025-10-09T21:41:25.341Z caller=main.go:184 level=info msg="Experimental OTLP write receiver enabled"
ts=2025-10-09T21:41:25.341Z 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"

Note that the path, “/etc/prometheus/prometheus.yml”, is the path of the file within the container, not the actual location on the host. There are several ways to get the file’s actual location on the host. One easy method is to view the docker-compose.yaml file. Within the prometheus service, in the volumes section, you will find the following line: 

      - ./services/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml”

This indicates the file is located at “./services/prometheus/prometheus.yml” on the host.

If we look at its permissions, we see that the user, “other” (represented by the three right-most characters in the permissions information to the left of the filename) are all dashes (“-“). This means the permissions are unset (they are disabled) for this user for reading, writing, or executing the file:

ubuntu@ubuntu:~$ ls -l services/prometheus/prometheus.yml
-rw-rw---- 1 ubuntu ubuntu 270 Aug 10 21:16 services/prometheus/prometheus.yml

For a description of default user roles in Linux and file permissions, see Red Hat’s guide, “Managing file system permissions”.

Since all containers in the Application Study Tool run as “other” by default, they will not have any access to this file. At minimum, they require read permissions. Without this, you will see the error above.

The Fix!

Once you figure out the problem lies in file permissions, it’s usually straightforward to fix it. A simple “chmod o+r” (or “chmod 664” for those who like numbers) on the file, followed by a restart of Docker Compose, will get you back up and running most of the time.

For example: 

ubuntu@ubuntu:~$ ls -l services/prometheus/prometheus.yml
-rw-rw---- 1 ubuntu ubuntu 270 Aug 10 21:16 services/prometheus/prometheus.yml
ubuntu@ubuntu:~$ chmod o+r services/prometheus/prometheus.yml
ubuntu@ubuntu:~$ ls -l services/prometheus/prometheus.yml
-rw-rw-r-- 1 ubuntu ubuntu 270 Aug 10 21:16 services/prometheus/prometheus.yml
ubuntu@ubuntu:~$ docker-compose down
ubuntu@ubuntu:~$ docker-compose up -d

The above is sufficient when read permission issues only impact in a few specific files. To ensure read permissions are enabled for "other" for all files in the services directory tree (which is where the AST containers read from), you can recursively set these permissions with the following commands:

cd services
chmod -R o+r .

For AST to work, all containing directories also need to be executable by "other", or the tool will not be able to traverse these directories and reach the files. In this case, you will continue to see permissions errors. If that is the case, you can set execute permission recursively, just like the read permission setting performed above. To do this only for the services directory (which is the only place you should need it), run the following commands:

# If you just ran the steps in the previous command section, you will still be in the services/ subdirectory. In the case, run "cd .." before running the following commands.
chmod o+x services
cd services
chmod -R o+X .

Notes:

• The dot (".") must be included at the end of the command. This tells chmod to start with the current working directory.
• The "-R" tells it to recursively act on all subdirectories.
• The "X" in "o+X" must capitalized to tell chmod to only operate on directories, not regular files. Execute permission is not needed for regular files in AST.
• For a good description of how directory permissions work in Linux, see https://linuxvox.com/blog/understanding-linux-directory-permissions-reasoning/

 

But Why Does this Happen?

While the above discussion will fix file permissions issues after they've occurred, I wanted to understand what was actually causing this. Until recently, I had just chalked this up to some odd behavior in certain Red Hat installations (RHEL was the only place I had seen this) that modifies file permissions when they are pulled from GitHub repos. However, there is a better explanation.

Many organizations have specific hardening practices when configuring new Linux machines. This sometimes involves the use of “umask” to set default file permissions for new files. Certain umask settings, such as 0007 and 0027 (anything ending with 7) will remove all permissions for “other”. This only affects newly created files, such as those pulled from a Git repo. It does not alter existing files.

This example shows how the newly created file, testfile, gets created without read permissions for "other" when the umask is set to 0007.

ubuntu@ubuntu:~$ umask 0007
ubuntu@ubuntu:~$ umask
0007
ubuntu@ubuntu:~$ touch testfile
ubuntu@ubuntu:~$ ls -l testfile
-rw-rw---- 1 ubuntu ubuntu 0 Oct  9 22:34 testfile

Notes:

• In the above command block, note the last three characters in the permissions information, "-rw-rw----". These are all dashes ("-"), indicating the permission is disabled for user "other".
• The umask setting is available in any modern Linux distribution, but I see it more often on RHEL.
• Also, if you are curious, this post offers a good explanation of how umask works: What is "umask" and how does it work?

To prevent permissions problems in the first place, you can run “umask” on the command line to check the setting before cloning the GitHub repo. If it ends in a 7, modify it (assuming your user account has permissions to do this) to something like “0002” or “0022”. This removes write permissions from “other”, or “group” and “other”, respectively, but does not modify read or execute permissions for anyone. You can also set it to “0000” which will cause it to make no changes to the file permissions of any new files.

Alternatively, you can take a reactive approach, installing and launching AST as you normally would and only modifying file permissions when you encounter permission errors. If your umask is set to strip out read and/or execute permissions for "other", this will take more work than setting umask ahead of time. However, you can facilitate this by running the recursive "chmod -R o+r ." and "chmod -R o+X ." commands, as discussed above, to give "other" read permissions for all files and execute permissions for all subdirectories in the directory tree. (Note that this will also enable read permissions on all files, including those where it is not needed, so consider this before selecting this approach.)

For a more in-depth discussion of file permissions, see Red Hat’s guide, “Managing file system permissions”.

Hope this is helpful when you run into this type of error. Feel free to post questions below.