How to Fix "Could Not Get Lock /var/lib/dpkg/lock" on Ubuntu

You type a command in your Linux terminal and get hit with: “Permission denied.” Maybe you tried to run a script, edit a config file, or install something — and Linux just says no.

This is one of the most common errors in Linux, and it exists for a good reason: Linux uses a strict permission system to protect your files and system from unauthorized changes. The error simply means your current user account doesn’t have the right permissions for what you’re trying to do.

The worst thing you can do is blindly run chmod 777 on everything. That “fixes” the error by giving everyone full access to the file — which is a massive security risk. Let’s fix it the right way.

Understanding Linux Permissions in 60 Seconds

Every file and directory in Linux has three permission types and three user categories:

Permission types:

• r (read) — can view the file contents
• w (write) — can modify the file
• x (execute) — can run the file as a program/script

User categories:

• Owner (u) — the user who created the file
• Group (g) — users in the file’s assigned group
• Others (o) — everyone else

When you run ls -l, you see permissions like this:

-rwxr-xr-- 1 john developers 1024 Feb 14 10:00 script.sh

Breaking it down:

• -rwx → Owner (john) can read, write, execute
• r-x → Group (developers) can read and execute, but not write
• r-- → Others can only read

5 Common Scenarios and How to Fix Each One

Scenario 1: “Permission denied” When Running a Script

You download or create a script and try to run it:

$ ./myscript.sh

bash: ./myscript.sh: Permission denied

Why: The file doesn’t have execute permission for your user.

Fix: Add execute permission:

chmod +x myscript.sh

Then run it again:

./myscript.sh

What chmod +x does: Adds execute permission for owner, group, AND others. If you want to restrict it to only the owner:

chmod u+x myscript.sh

Scenario 2: “Permission denied” When Editing a System File

You try to edit a system configuration file:

$ nano /etc/nginx/nginx.conf

[ Error writing /etc/nginx/nginx.conf: Permission denied ]

Why: System files in /etc/, /usr/, /var/ are owned by root. Your regular user can’t modify them.

Fix: Use sudo to run the command with root privileges:

sudo nano /etc/nginx/nginx.conf

Enter your password when prompted. The file opens with root access, and you can edit and save it.

Important: Only use sudo when you genuinely need root access. Don’t get into the habit of prefixing every command with sudo.

Scenario 3: “Permission denied” When Accessing Another User’s Files

You try to read a file in another user’s home directory:

$ cat /home/alice/notes.txt

cat: /home/alice/notes.txt: Permission denied

Why: Linux home directories are private by default. Only the owner (alice) can access files inside.

Fix — Option A: Ask the file owner to change permissions:

# Run as alice or root:

chmod o+r /home/alice/notes.txt

Fix — Option B: If you have sudo access:

sudo cat /home/alice/notes.txt

Fix — Option C: Change file ownership to yourself (only if appropriate):

sudo chown yourusername /home/alice/notes.txt

Scenario 4: “Permission denied” When Installing Packages in a Directory

You try to install something or write to a directory you don’t own:

$ pip install package-name

ERROR: Could not install packages due to an EnvironmentError: Permission denied

Why: You’re trying to install to a system directory (/usr/lib/) without root access.

Fix — Option A (Recommended): Install for your user only:

pip install --user package-name

Fix — Option B: Use sudo (installs system-wide):

sudo pip install package-name

Fix — Option C: Use a virtual environment (best practice for Python):

python3 -m venv myenv

source myenv/bin/activate

pip install package-name

Scenario 5: “Permission denied” When Accessing a Mounted USB/External Drive

You plug in a USB drive and can’t write to it:

$ cp file.txt /media/usb/

cp: cannot create regular file '/media/usb/file.txt': Permission denied

Why: The drive was mounted with restricted permissions, or the filesystem (like NTFS) doesn’t map Linux permissions correctly.

Fix for NTFS drives:

sudo umount /media/usb

sudo mount -o rw,uid=$(id -u),gid=$(id -g) /dev/sdb1 /media/usb

This mounts the drive with your user as the owner, giving you full read/write access.

Fix for ext4 drives:

sudo chown -R $(whoami) /media/usb

The chmod Number System Explained

Instead of letters (rwx), you can use numbers:

Three digits = Owner, Group, Others. Examples:

Never use chmod 777 unless you have a very specific temporary reason. It gives everyone full access — including write and execute — which is a security vulnerability.

Quick Reference: Which Command to Use

Frequently Asked Questions

What does “chmod 777” do and why is it bad?

chmod 777 gives read, write, and execute permissions to everyone — owner, group, and all other users on the system. This means any user or process can modify or delete the file. It’s a security risk, especially for scripts (which could be modified to run malicious code) and config files (which could be changed to compromise services).

What’s the difference between chmod and chown?

chmod changes what actions (read/write/execute) are allowed on a file. chown changes who owns the file. They solve different problems: if you own the file but can’t execute it, use chmod. If someone else owns the file and you need access, use chown (with sudo) or ask them to change permissions.

I used sudo and it still says “Permission denied.” What now?

This can happen if: (1) your user isn’t in the sudoers group — run groups to check if “sudo” is listed, (2) the filesystem is mounted as read-only — check with mount | grep " on ", or (3) the file has immutable attributes — check with lsattr filename and remove with sudo chattr -i filename.

How do I fix “Permission denied” for all files in a folder?

Use the -R (recursive) flag: chmod -R 755 /path/to/folder. This changes permissions for the folder and everything inside it. Be careful with recursive chmod on system directories — only use it on your own files and folders.

Should I always use sudo when I get “Permission denied”?

No. Sudo gives you root power, which bypasses all permission checks. Only use it when you genuinely need to modify system files or perform administrative tasks. For your own files, fix the permissions with chmod instead.

Conclusion

The “Permission Denied” error is Linux doing its job — protecting files from unauthorized access. The fix depends on the situation: use chmod to change permissions, chown to change ownership, or sudo for system-level tasks. Never default to chmod 777 — learn the number system and give only the permissions that are actually needed.

Last updated: February 2025 | Tested on Ubuntu 22.04/24.04, Debian 12, and Fedora 40