File permissions on Linux can be a pain. You can either understand them in symbolic mode (basically, alphabet soup--i.e., drwxrwxrwx), or you can master them in octal mode (i.e., 777--which roughly translates to "Open the gates of Mordor!"). While symbolic mode might acutually be the more human-readable format; octal mode feels a bit more intuitive, and in my experience is what I see referenced more often on the interwebz (i.e., StackOverflow). The problem?--Linux generally defaults to symbolic mode on the command line--such as when you run ls -l. Here's a short script that helps cope with this. Run it, and it'll give you the permissions for a file, directory, or contents of a directory in octal mode.

It's just the way of Linux, especially on legacy hardware: every now and then you screw things up beyond repair--like when you change graphics drivers and can no longer access a login screen. I recently got myself in a pinch and, after hitting my head against a wall for several hours, decided that I'd look at reinstalling Ubuntu and restoring from a Duplicity/Deja Dup backup. Unfortunately, my first attempts to restore the backup presented me with an error that seems to be somewhat common. The fix, as often seems to be the case, was a simple permissions change.

This is probably a no-brainer for advanced Linux users, but for newbies it may strike as awkaward that if you create/partition a disk with one user on your computer, another user won't automatically have "access" to it. This is a good opportunity to revisit the function of permissions in Linux--a quick review of Users and Groups.

A branch management error that can seemingly come out of nowhere. Don't worry, there's an easy fix for this one. The key may be in understanding the real power of Sudo in Linux.