Permission denied: sudo, ownership, and not wrecking /usr

Permission denied means the kernel refused the operation. Adding sudo blindly, or running chmod -R 777, is how home directories and web sites get broken.

Read the error

If a file is not executable, you get permission denied when you try to run it. If you do not own the file, writes fail. Check with:

ls -ld filename
id
whoami

ls -l shows owner, group, and mode. Your user should own files in your home directory.

When sudo is correct

Use sudo to install packages, edit files in /etc, and restart services. You should still understand the command. Example that is reasonable:

sudo apt install curl
sudo systemctl restart ssh

Do not use sudo to edit files in your home directory. That creates root-owned files you then cannot save from the desktop editor.

Fix a directory you locked

If you ran sudo inside ~/ and now cannot save documents:

sudo chown -R "$USER:$USER" "$HOME"

That restores your home to you. Do not run chown -R on / or /usr.

chmod 777 is not a fix

World-writable files are a security hole and a later support nightmare. For a web site, the usual pattern is: files 644, directories 755, and the web server user owns only the directories that must be writable (uploads, cache). WordPress has its own repair steps; do not chmod the whole public_html to 777.

sudoers

If you are not in sudoers, sudo will refuse. On Ubuntu, the first user is in group sudo. Adding a user (as root from recovery, or from another admin):

sudo usermod -aG sudo otheruser

Log out and back in for group changes to apply.