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?"
Beautiful story. Feel that we've all been there. Every now and then, when the assumption is that the stupid piece of tech isn't working, and there it is, just functioning as intended :)
Had a similar experience with Mint (of all distros) on an old laptop where it would not detect the headphones I plugged in. Spent like 30 minutes troubleshooting the settings/configuration and googling. Turns out the cable was weird and I just needed to not push it in too deep for it to be detected.
Been there with those old printer cables that had the two thumb screws.
I spent way too long troubleshooting print problems turned out with some cables if you dont screw the thumb screws all the way in you don't get a good cable connection.
Once helped a nice old lady troubleshooter her computer. Everything was yellow. Checked monitor settings three times. Checked Windows for f.lux. Checked Windows video settings. Reverted drivers. Updated drivers.
Educator here.
This is called "discovery learning".
(The alternative to discovery learning, "direct instruction", would be if someone had told OP about these permissions before OP got themselves into a pickle)
When discovery learning is successful, it leads to better learning outcomes.
Compared to direct instruction, you learn the material more deeply and will have better recall of the material, often for the rest of your life.
The downsides to discovery learning are that it's very time-consuming, very frustrating, and many students will just fail (give up) before learning is completed.
It happened to me countless times that I was suffering with a task for hours and hours and hours, then finally found what the problem was. Then a few weeks later, facing the same issue again somewhere else, I only remembered the fact that I had that same issue weeks ago, but I completely forgot what the solution was.
Weirdly enough, sometimes it's indeed a lifelong experience and I can remember the solution forever. I don't really know what it depends on.
Reminds me of the adage "you didn't pay me $5,000 for turning that bolt. You paid me $5,000 because I knew which bolt to turn." Experience and knowledge is valuable.
But then you get the pleasure of making it submit. My Minecraft server is now running in GNU screen just like I wanted it to, and SELinux can only look on and whimper softly.
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"
if a windows system is behaving funny, it has to do with virus.
Not always true. Sometimes, it's a driver issue. (Usually, a reinstall can fix the issue.) Or it could, very rarely, even be a BIOS/ UEFI issue. (Don't touch it unless you know what you're doing, and only download updates from your manufacturer's website.)
it has to do with virus. If a Linux system is behaving funny, it has to do with permissions"
Windows permissions are way more complex than Linux though, unless you're using Linux ACLs. Standard Linux permissions just have read, write, and execute permissions for the user, group, and world. Windows (and Linux ACLs) allow any number of different users or groups to have different permissions.
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.
There needs to be a Linux kernel fork that when you try to execute a directory executes all programs in the directory. In parallel. Juuuuuuuust to fuck with people who might accidentally execute the /usr/bin directory.
Those of us who use the autocd feature of shells "execute" directories all the time. For example I'd type just /usr/bin RET if I wanted to cd to /usr/bin.
For directories, it’s permission to cd into it. Read is whether you can list files, and write is remove, rename, or create new files. Don’t ask questions about the secret sticky bit
The x permission on directories is exactly for this purpose. You can use the directory. You cannot read (requires rx), you cannot write (w), but you can 'cd' and operate on files in the directory.
This is important, you can lock someone out from a directory tree buy not giving them 'x' on the root. So, if your home is rwx------, no one but the owner can do anything in your home. This is effective even if some files and subdirectories have less restrictive permissions.
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)?
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.
I set 777 to my whole file system on a install of Ubuntu back in the day and it does indeed fuck the install in lovely ways. I didn't bother attempting recovery. Nice learning experience.
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.
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.
Yup. Took me weeks to figure out why I explicitly need to use sudo nvim for my nginx config on my Pi, while on my server my little helper script could automatically use sudo for me. Turns out, I chmoded the sites-available and sites-enabled on my pi to 644 but left them untouched on my server.
I still don't know what numbers would be 644 but with execute permissions, but in the end, idc.
I often go chmod -R go+rX . if I want to give read-only access to whatever I'm working on to everyone else. The capital X only sets the executable bit on directories.
644 and 755 are the two most useful octal codes to remember because they make up the majority of files on your system. 644 is user read/write but read-only for everyone else. 755 adds execute to that, useful for scripts and directories.
Other than that, the most common other things are setting access for group and others to zero, so your ~/.ssh directory is 700 (rwx for you, no access for anyone else) and the private keys in it are 600, rw for you, no access for anyone else).
For those that don't know, you can use three numbers, zero through eight, with the chmod command. it takes the binary of each digit to set the permissions.
One person would have responded with "LMGTFY". Another would have said "Why are you trying to do it that way? You should do it this way". Another would have asked what distro they were using, and regardless of the answer, bullied them for their choice. Yet another would have given a very confident and wrong answer. One more would have suggested they use kde instead of genome. And finally, a mod would mark the question as duplicate of another unanswered question and lock it. Thats why.
Why ask for help if I can spend hours in "terminal flow" where I know every three character sequence for CTLR+R to suggest the last 10 commands in the history?
Thank you! I only switched to Linux in 2022. I came for the privacy and performance, and stayed for the customisation, the FOSS philosophy and the terminal experience.
I would argue that this is something that should be taught in every undergraduate Operating Systems course. But if someone posting it here benefits teens, self-taught hobbyists, and old-timers getting back into the field so be it.