E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied) followed by are you root? means apt-get ran as an ordinary user. Installing packages needs root: run the same command with sudo in front, as a user who is allowed to use sudo.

This is not the "held by process" lock message, where another apt is running. Here no other process was involved; the user simply had no right to open the file.

The error

$ su maria -c 'id'
uid=1001(maria) gid=1001(maria) groups=1001(maria)
exit code: 0
$ su maria -c 'apt-get install -y jq'
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?
exit code: 100

The same user got a different lock file for apt-get update, and dpkg its own message:

$ su maria -c 'apt-get update'
Reading package lists...
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
exit code: 100
$ su maria -c 'dpkg -r jq'
dpkg: error: requested operation requires superuser privilege
exit code: 2

Why it happens

Error 13 is the system's "permission denied". The user maria (uid 1001, in no group but her own) could not open the lock files under /var/lib/dpkg and /var/lib/apt/lists, so apt-get stopped there and returned 100 without installing or downloading anything (apt-get update printed Reading package lists... first). The are you root? at the end of the second line is apt's own hint. dpkg -r refused in the same way with requires superuser privilege and exit code 2.

Check who you are before anything else: id printed uid=1001(maria), not root, and that user needed sudo. The lock file named in the message tells you which command was refused: lock-frontend for the install, /var/lib/apt/lists/lock for apt-get update.

The fix

$ echo 'maria ALL=(ALL) NOPASSWD: ALL' > /etc/sudoers.d/maria-test
exit code: 0
$ su maria -c 'sudo apt-get install -y jq'
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  libjq1 libonig5
The following NEW packages will be installed:
  jq libjq1 libonig5
...
Setting up jq (1.7.1-3ubuntu0.24.04.2) ...
Processing triggers for libc-bin (2.39-0ubuntu8.9) ...
exit code: 0

With sudo the same user installed jq and the command returned 0. The NOPASSWD rule was written as root for this test so that sudo would not stop to ask for a password; on your own machine keep the password prompt and type your password when sudo asks. A user without a sudo rule was not tested here.

How it was reproduced

The capture was made in an ubuntu:24.04 container (Ubuntu 24.04.5 LTS, apt 2.8.3, dpkg 1.22.6) on Docker Engine 29.9.3, standing in for Ubuntu in WSL. As root, sudo was installed and a test user maria was added with useradd -m -s /bin/bash maria; each command was then run as that user through su maria -c, first without sudo and then with it.

Frequently asked

How do I fix 'Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)'?
Run the command with sudo, for example sudo apt-get install -y jq. In the test the same user got the error without sudo and a clean install with it.
Why does apt-get update say 'Unable to lock directory /var/lib/apt/lists/'?
In the test it was the same cause: apt-get update ran as an ordinary user, could not open /var/lib/apt/lists/lock with error 13 and returned 100.
What does 'dpkg: error: requested operation requires superuser privilege' mean?
dpkg was run as a user who is not root. In the test dpkg -r jq as the user maria printed it and returned exit code 2.

More decoded errors in the Fixes category. If the message says the lock is held by a process instead, see Could not get lock /var/lib/dpkg/lock-frontend.