If it makes you feel any better, I decided earlier today to experiment with "castnow", a command-line program for casting to a Chromecast device.

I grabbed the url of a video off of Archive.org, used wget on a box I was ssh'd into to download the video, and then ran my "castnow" command to cast it to the Chromecast.

I got a progress bar and current/total time on the TV, but aside from that only a black screen and no audio.

I tried getting the latest version of "castnow" from the Git repo. I tried transcoding 7 different ways with FFMPEG. A bunch of things.

Finally, copied the video to my local machine and ran it in mpv.

The video itself was solid black with no audio and the Archive.org page had comments on it saying "why is there no video or audio?"

I tried a different video and it worked fine.

Back in the dark, old days of Linux I spent 5-6 hours digging through dbus events and X11 configs to get my mouse working. It was unplugged.

In my defense, in those days, Linux was such an insane asylum that diving into dbus and X11 as a first step was usually the logical approach.

You can always cd's nuts

No, you just had a 3 hour learning experience.

SELinux enters the chat

Sure you own it, your groups owns it, its permissions are 777, SELinux says GEEEEEEET FUUUUUUCKED.

A friend of mine told me a long time ago: "if a windows system is behaving funny, it has to do with virus. If a Linux system is behaving funny, it has to do with permissions"

You wasted 3 hours of your life so far lol

But yeah. I find the most mysterious and time-consuming of problems are usually caused by a very minor detail that is so obvious it gets overlooked immediately.

And even if you know that's probably the case, sometimes your brain will just discard information that isn't consistent with its assumed reality, and it tells you the piece of code you just read is fine when it's obviously not.

Troubleshooting/debugging is fun.

I remember myself asking why directories had x flags in their permissions. Like, you don't execute them. What do they use the x flag for?

I love posts like these because they help me avoid mistakes I would've definitely made too. Thanks OP!

ls reaction to this is unexpected:

$ mkdir foo
$ echo Foo > foo/file
$ chmod a-x  foo
$ ls -l foo
ls: cannot access 'foo/file': Permission denied
total 0
-????????? ? ? ? ?            ? file

I expected to just get a "Permission denied", but listing the content it can still do. So x is for following the name to the inode and r for listing directory content (i.e. just names)?

sudo chmod -R 777 /

Edit: don't do this, it will allow everyone and everything to read and modify all files of all mounted filesystems, this includes your personal files, system wide passwords, config files, everything and might break the whole system as not all files are meant to have these permissions, e.g. mapped hardware settings or your ssh key store.

sudo comes with immense power, do not, under any circumstances, enter commands you found on the internet without an intense look about what they do and what their implications could be. Never sudo or doas, etc., without a strong and valid reason.

No one mentioned ACLs so far. If you see a + using ls -l like this drwxrwx---+, you have an access control list entry.

access control lists

Ouch. I'm sorry you had to find out that way. But in the plus side, you'll never forget.

I worked in a job with build scripts. Developers would list what they wanted in a drop-down menu on a website, with very few "fill in the blanks." This would create a template, which was sanity-checked.

One of the "fill in the blanks" was "home directory of user, if not default /home/username." Some people filled it in, some didn't. A lot of "users" might be apps with /home being "/opt/appname" "/var/www/html" or something. We checked to make sure that directory existed, if not, create, and set permissions. Easy peasy, all automated. Ran this lots of times.

Then one day, the script failed. Borked the whole box. Sometimes the VM was corrupt, so delete VM and try again. Usually worked. But this time, the build kept failing. The box went down. Wasn't even bootable. This happened several times with this one build. So we mounted the borked drive under a new VM and checked out the logs. Just like the dessert stage of Willy Wonka chewing gum, it always failed at the last stage: making /home directories.

It would create them, then halt that it could not find bash. We looked for bash on the bad drive, and it was the usual /bin/bash shortcut to /usr/bin/bash and we were truly puzzled. I did a chroot to the drive and NOTHING worked. It just hung. That was the first clue.

The second was looking through the build script (in bash, which we didn't write) and checking the steps. Looked it the logs. Always died at creating some user named sapadm, the user for the HANA database. Eventually, I checked the configure file, and noticed it was the only user with the odd home directory "/usr/sap." Then it hit me: the permissions.

The script, thinking it was a home directory, did a chmod - R 755 for all directories and chmod - R 644 for all files! That meant, while creating home, it made everything under /usr not executable anymore! Holy shit, no wonder nothing worked! So we commented out that user in the config, ran the build again, and we were good! We created the sapadm by hand, and then later fixed the bug in the script.

SANITIZE YOUR DATA. Or you might turn Violet Beauregarde into a blueberry.

Learned that when dealing with Ansible:

• Folder in most cases 755
• File in most cases 644 or 755 if executable.

I have wasted lots of time on this once, long ago.

Here's another one I wasted time on. Mount point didn't have proper permissions (SunOS I think it was). Couldn't access the mounted filesystem.

I once wasted 2 hours on getting an ssl cert working on an irc server by just giving its user access to my nginx certs, which turned out to also need +x. That was when I realized everything I knew about the execute permission was wrong.