Gitlab CI Error – Cannot create local repository at: /.m2/repository

When you are using downstream pipelines in Gitlab CI for complex Maven Projects as I do, you may have stumbled accross this error at least once: Cannot create local repository at: /.m2/repository. The Gitlab runner tries to create a local Maven repository at /.m2/repository – so in the topmost directory – and fails horribly due to an obvious lack of permissions. Let‘ see what happens here.

The Gitlab CI Setup

In my case I had a shell-based Gitlab runner that executes a test suite based on a few artifacts published by a Docker runner. Due to versioning and system test level realism reasons I was not able to use the artifacts directly. Unfortunate, but it shouldn’t pose that kind of a problem, does it?

Now when it comes to cloning the test suite on my shell runner, this cryptic error has been dropped. And naturally I was like „WTF is this runner trying to do!?“

The root cause in Gitlab CI downstream jobs

What I was not aware of is that per default the „child job“ inherits all the custom and Gitlab-provided runner variables from the triggering parent job that is still executed on a Docker runner. Now since the trigger happens from a Docker runner job, the variables my child job receives are poison for a baremetal environment that is my shell runner. Not least because things actually do happen at / in a Docker-based Gitlab execution environment, which is perfectly fine, but not on a shell runner.

The solution: What I had to do to make the CI jobs work

To fix the problem I had to set this on my trigger job definition:

This did not just fix the error for me, but it also made perfect sense. Due to the different execution environments – shell vs. docker and project A vs. project B – I have a different set of requirements for my Gitlab CI test job. Therefore we have another case of an error leading to better software design. In addition I learned another piece of Gitlab’s sometimes quite obscure default settings.


I hope this helps you during your day to day journey through the jungle that are Gitlab CI downstream jobs. As I’m an avid QA engineer, so if you want to read more about writing actual automated tests. Also I take care of deeper coding basics like working with threads in java. If you’d rather want to read up about Gitlab CI’s inherit keyword, here’s the link to the relevant section of the official Gitlab CI documentation. Feel free to have a look!

Have a great weekend everybody!

Share it with:

AccessDenied in psutil

psutil is an interesting Python package that provides us with valuable insights about running processes, their memory and CPU usage and many more key aspects for monitoring and profiling processes across all major platforms. Thus, it is an incredibly useful tool for system admins, developers and testers alike. Now one of my favourite methods is cmdline(). Defined in the package’s Process class, it yields the whole CLI command of a running process in array form. There is one important catch on Windows though that got me kinda by surprise: While iterating casually through all my processes I suddenly got an AccessDenied error.

What did I try?

For an advanced verification in a process management – related test case I wanted to print the executed CLI command in a log file, so basically this:

import psutil

for pc in psutil.process_iter():

But that will just throw a painful AccessDenied error at us. Uff.

Why did that happen?

The reason is that psutil is quite consequent: It really lists every running process. That means even SYSTEM or root processes . That’s okay, it might even be interesting in one case or another, and you can still access selected attributes like the name() of a root process, if you want. But for me, it doesn’t suffice. I want to see the full-fledged cmdline(), but I understand that SYSTEM processes are none of my business. Once I came to term with that fact, the solution was easy: We just skip them.

The solution

What I did was applying a try-except around the loop’s inner statement:

import psutil

for pc in psutil.process_iter():
    except psutil.AccessDenied:

The continue statement will make sure that the processes that I’m not supposed to see are happily skipped without hurting the rest of the program flow.

But what if I need to monitor foreign processes?

In that case, we would need to execute the script within the process owner’s user context. That might be a bit fiddly in Windows depending on the use case, but of course that’s still possible. Just remember to keep the try-except block, because there still will be processes you wouldn’t be allowed to see.

Mine, for example.


So far for today. I hope this little Q3A (quick question quick answer) could shed some light upon that surprising AccessDenied error. If you want to learn more about psutil, I strongly recommend the readthedocs page. Otherwise, if you want to see more quick tips, I have one more for Python about environment variables. That one covers Python’s environment variable handling. As an alternative, if you are – like me – into containers, here is a handy docker ps trick useful for monitoring tasks as well.

Happy coding!

Home » Administration
Share it with:

docker ps formatting – Cheat Sheet

Checking the status of Docker containers is an important starting point, when it comes to debugging container clusters. docker ps is an ideal tool to get you started. Unfortunately, the output can sometimes be quite verbose and overwhelming.

The --format parameter is supposed to ease the pain here, but Go templates can be quite tedious to write every time, too. To counter that a little, I reveal my favorite ready-to-alias docker ps calls in today’s post. I hope they make your everyday Docker life a little easier.

# Are my expected containers up?
docker ps --format "table {{.Names}}\t{{.Status}}"

# What ports do my containers expose?
docker ps --format "table {{.Names}}\t{{.Ports}}"

# What networks are my containers assigned to?
docker ps --format "table {{.Names}}\t{{.Networks}}"

All of them can be extended with more docker ps command line parameters, even when aliased later on.

As you may have noticed, my first column is always the container name followed by the property I’d like to analyse. This is my personal way to keep the output compact and focused on the problem at hand, but of course you can query any property you like. Check out the official documentation for a comprehensive list of available properties and pick what you need for the task.

Do you have a favourite formatting? Or do you want to talk about any other question? Feel free to let me know in the comments below. I plan to publish more cheat sheet-style posts in the future. This helps me out to share recent learnings in a focused way and provides you with quick help and valuable insights. You can find another example here, where I demonstrate how to set up Linux users with low maintenance work afterwards. Or if you are into Rust like I am, the Rust modules cheatsheet might be a valuable companion, when it comes to structuring your code with Rust Modules.

Until next time!

Home » Administration
Share it with:

Create a New Linux User

To create a new Linux user is one of the most common task in traditional Linux system administration. It is so popular that there are even two command line utilities fully dedicated to the task: adduser (Debian and its derivates) and useradd (all). And since it’s so popular many different administrators have many different solutions for the same problem.

Here I present mine. Note that I prefer sudo over working as root, but the steps work with root as well. Just omit the sudos.

  1. Create a personalised user group.
    $ sudo groupadd newuser
  2. Create the user with a home directory, a good default shell, its user group and further desired groups assigned.
    $ sudo useradd -m -s /bin/bash -g newuser -G sudo,orga newuser
  3. Set the user’s initial password.
    $ sudo passwd newuser

Step summary for your automation needs

sudo groupadd newuser
sudo useradd -m -s /bin/bash -g newuser -G sudo,orga newuser
sudo passwd newuser

Prepare SSH access for our newly created Linux user

If required, we can now enable the user to connect to our machine via SSH. We assume that the SSH demon is up and running and the user’s public key is available on our machine.

  1. Change into the user’s home directory.
    $ sudo cd /home/newuser/
  2. Create the .ssh directory.
    $ sudo mkdir .ssh
  3. Set the directory permissions of .ssh to 0700 (read-write-execute only for the user).
    $ sudo chmod 0700 .ssh/
    Note that the execute permission is necessary to access the directory; read does not suffice. This might be a little counterintuitive for new admins. (It surely was for me.)
  4. Change into our meticulously prepared directory.
    $ sudo cd .ssh/
  5. cat the user’s public key into a new file called authorized_keys.
    sudo cat /path/to/pubkey > authorized_keys
  6. Set the authorized_keys file permissions to 0600.
    sudo chmod 0600 authorized_keys
  7. Make sure that everything we created is assigned to the new user.
    cd ..
    sudo chown -R newuser:newuser .ssh/

    Now the user should be able to connect to us with SSH.

Step summary for your automation needs

sudo cd /home/newuser/
sudo mkdir .ssh
sudo chmod 0700 .ssh/
sudo cd .ssh/
sudo cat /path/to/pubkey > authorized_keys
sudo chmod 0600 authorized_keys
  • cd .. sudo chown -R newuser:newuser .ssh/
  • Conclusion

    User creation is a staple task when working with Linux servers, and now you have a solid solution at hand that will lighten up your daily workload. So long. I hope this little sheet was useful to you. Usually I write about Rust, test automation and business topics. If you want to read more from me, this post combines Rust and test automation. In my day job, I also do lots of test automation, but here my key focus is Java. Hence, if you are rather interested in that, I’m also talking about fuzzing with Java.

    Or if you miss a detail, or you want to get your hands a little dirtier than just cheat sheet level, Linuxize has an in-depth post about the nitty gritty parts of user administration. It really helped me out a lot in the past.

    Have a nice day!

    Home » Administration
    Share it with: