• TootSweet@lemmy.world
    link
    fedilink
    English
    arrow-up
    366
    arrow-down
    2
    ·
    1 year ago

    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.

  • thelastknowngod@lemm.ee
    link
    fedilink
    arrow-up
    157
    ·
    1 year ago

    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.

    • init@lemmy.ml
      link
      fedilink
      arrow-up
      48
      ·
      1 year ago

      Jesus Christ. I’ve never been so thankful for being a Linux noob in my life. That sounds awful.

        • SzethFriendOfNimi@lemmy.world
          link
          fedilink
          arrow-up
          22
          ·
          1 year ago

          Remember make

          Oh wait. Missing something.

          Download it.

          Tar unzip make missing something else. Tar unzip make.

          1 hour later. What was I doing?

        • bpm@lemmy.ml
          link
          fedilink
          arrow-up
          8
          ·
          1 year ago

          I owe much of my career to trying to set up Linux From Scratch two decades ago. While it’s a much better experience installing Linux nowadays, there’s a lot to be said for the experience spending your weekend debugging a system will give you.

    • edric@lemm.ee
      link
      fedilink
      arrow-up
      18
      ·
      1 year ago

      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.

    • BCsven@lemmy.ca
      link
      fedilink
      arrow-up
      14
      ·
      1 year ago

      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.

      • cobra89@beehaw.org
        link
        fedilink
        arrow-up
        7
        ·
        edit-2
        1 year ago

        Ah yes the good ol’ LPT ports. Back in the days of pin printers and them catching on fire. Good times.

        • Elise@beehaw.org
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          I like that it has those little inside bevels to guide the pins. More connectors should have that.

    • grue@lemmy.world
      link
      fedilink
      English
      arrow-up
      13
      ·
      edit-2
      1 year ago

      Back in the dark, old days of Linux I spent 5-6 hours digging through dbus events

      That’s not possible. In the dark, old days of Linux, dbus didn’t exist yet.

    • mindbleach@sh.itjust.works
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      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.

      Jiggled the cable.

    • taaz@biglemmowski.win
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      I am still bitching when I have to touch anything dbus, x11 or xdg.
      Also, finding where an environment variable comes from is fun too.

    • duncesplayed@lemmy.one
      link
      fedilink
      English
      arrow-up
      18
      ·
      1 year ago

      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.

      Consider yourself one of the lucky ones, OP.

      • El Barto@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        If discovery learning is frustrating in class, you must adjust it. It can’t be too easy or too frustrating.

        And yes, usually the mental model a student forms from a lesson after doing some discovery learning has strong foundations.

      • helmet91@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        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.

    • TangledHyphae@lemmy.world
      cake
      link
      fedilink
      arrow-up
      8
      ·
      edit-2
      1 year ago

      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.

  • deadbeef79000@lemmy.nz
    link
    fedilink
    arrow-up
    71
    arrow-down
    2
    ·
    1 year ago

    SELinux enters the chat

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

        • Possibly linux@lemmy.zip
          link
          fedilink
          English
          arrow-up
          6
          arrow-down
          1
          ·
          1 year ago

          Honestly I’ve never had to do anything but the defaults so I can’t really testify to that.

          • aes@lemm.ee
            link
            fedilink
            English
            arrow-up
            10
            ·
            edit-2
            1 year ago

            It’s a bit of an ordeal on the server-side of things if you don’t know what SELinux does. These days “is SELinux fucking something up?” is a regular on my troubleshooting list, though.

    • Kazumara@feddit.de
      link
      fedilink
      arrow-up
      9
      ·
      1 year ago

      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.

  • pocopene@lemmy.world
    link
    fedilink
    arrow-up
    64
    ·
    1 year ago

    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”

    • Gestrid@lemmy.ca
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      1 year ago

      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.)

    • dan@upvote.au
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      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.

  • Yardy Sardley@lemmy.ca
    link
    fedilink
    arrow-up
    45
    ·
    1 year ago

    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.

    • Elise@beehaw.org
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      1 year ago

      Oh god that reminds me of those cases where it IS a language bug. It’s like just not part of reality somehow so you don’t see it.

  • vsis@feddit.cl
    link
    fedilink
    English
    arrow-up
    44
    ·
    1 year ago

    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?

    • TootSweet@lemmy.world
      link
      fedilink
      English
      arrow-up
      33
      ·
      1 year ago

      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.

      • SzethFriendOfNimi@lemmy.world
        link
        fedilink
        arrow-up
        16
        ·
        1 year ago

        Or worse… In order. Based on last Modified date. And use that as the basis for some scheduling agent where timing and order of execution is essential.

      • donio@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        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.

    • TQuid@beehaw.org
      link
      fedilink
      English
      arrow-up
      22
      ·
      1 year ago

      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

    • _s10e@feddit.de
      link
      fedilink
      arrow-up
      17
      ·
      1 year ago

      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.

    • atzanteol@sh.itjust.works
      link
      fedilink
      arrow-up
      7
      ·
      edit-2
      1 year ago

      It’s necessary if you want to give somebody rw access to a subdirectory but not the parent.

      The parent gets “x” and the child gets “rwx”.

      This way you can have multiple users with their own directories under, say, /var/www/html but restrict access to /var/www/html itself.

      If the user doesn’t have “x” then they can’t see anything in that directory at all.

  • Pyro@programming.dev
    link
    fedilink
    arrow-up
    44
    ·
    1 year ago

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

  • lloram239@feddit.de
    link
    fedilink
    arrow-up
    41
    arrow-down
    1
    ·
    1 year ago

    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)?

    • Zoidberg@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      You can still read the contents of the directory because you have -r on it. If you just run ls foo you’ll see your file on there, no problem.

      However, without -x you cannot read metadata in that directory. That’s why all information about the file shows as question marks.

  • neonred@lemmy.world
    link
    fedilink
    arrow-up
    49
    arrow-down
    10
    ·
    edit-2
    1 year ago

    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.

        • SorteKanin@feddit.dk
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          Actually curious how though - I mean won’t it just let all programs/users access everything? Or do some system stuff rely on permissions for certain behavior?

          • Tekhne@sh.itjust.works
            link
            fedilink
            arrow-up
            4
            ·
            1 year ago

            SSH will definitely break, I’ve had this issue before. If your private key in the .ssh dir is too open, ssh won’t let you use it.

          • palordrolap@kbin.social
            link
            fedilink
            arrow-up
            3
            ·
            1 year ago

            Theoretically yes, but yes, in that order.

            I’ve worked with Linux for decades at this point and I’m still not 100% sure exactly what breaks; it’s a mistake you make once, if at all, and you’ll only get a little way into even trying to figure out how to fix things before you throw your hands up in disgust and reinstall / restore the OS (or whatever subdir was affected).

            If I was to hazard a guess, it’s the kernel itself that balks, but there are other, almost as fundamental things (lib*.so files and the like) that may also be deliberately fussy.

            • nixcamic@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              1 year ago

              I think it’s systemd not the kernel. If only Linux had “repair permissions” like vintage MacOS.

              • palordrolap@kbin.social
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                Recursive chmod (or chown) has been breaking things since before systemd was a thing, so even if systemd is now responsible for stopping things from working, it can’t have been that previously, especially at the time I might have done something silly.

                As for repairing permissions only, I suppose it would be possible, assuming the system still works (or can somehow be encouraged to do so) to copy only the permissions (or at least infer them) from a backup or something rather than the whole files.

                • nixcamic@lemmy.world
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  1 year ago

                  Probably init before that then. I don’t think the kernel cares unless explicitly told to care, I’ve seen some embedded Linux with interesting permissions.

              • Synthead@lemmy.world
                link
                fedilink
                English
                arrow-up
                1
                ·
                1 year ago

                You don’t typically have permissions “become defective” or need them to be “repaired” in a Linux system. Nearly all system files, with their permissions, are included in packages. Everything else should be considered user data.

                If you logged in as root and did something dumb, you could attempt to fix the permissions by reinstating packages.

          • Phrodo_00@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            1 year ago

            I actually don’t know how many programs do this, but several check that file permissions are correct or refuse to work. Sudo and ash are 2 of them. I could see /etc/shadow being readable and writable by everyone being a problem too, but I don’t know.

    • lseif@sopuli.xyz
      link
      fedilink
      arrow-up
      24
      ·
      1 year ago

      the 777 stands for ‘lucky jackpot number’, as in ‘youre lucky if you dont break your entire system’

    • MTK@lemmy.world
      link
      fedilink
      arrow-up
      22
      arrow-down
      1
      ·
      1 year ago

      This is so useful! Now I can just run:

      rm -rf /

      Without the sudo!

    • drdiddlybadger@pawb.social
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      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.

    • redcalcium@lemmy.institute
      link
      fedilink
      arrow-up
      16
      ·
      1 year ago

      More than a decade of using linux and I still can’t remember setfacl syntax. I have better luck remembering tar syntax.

        • pelotron@midwest.social
          link
          fedilink
          English
          arrow-up
          5
          ·
          1 year ago

          And tar -czf compress ze file. I saw someone post these mnemonic devices a while back and now I actually remember tar commands. Amazing!

        • Markaos@lemmy.one
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          This is a very useful way to remember it, but nowadays it’s better to drop the z (which immediately makes the mnemonic more forgettable, of course). tar can autodetect compression now, so tar -xf should work on anything from plain tar archives over tar.gz to more unusual compression algorithms like tar.xz or tar.bz2.

          (the z is specifically for gzip)

  • Punkie@lemmy.world
    link
    fedilink
    arrow-up
    27
    ·
    edit-2
    1 year ago

    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.

    • neonred@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      1 year ago

      To change all the directories to 755 (drwxr-xr-x):

      find /opt/lampp/htdocs -type d -exec chmod 755 {} \;

      To change all the files to 644 (-rw-r--r--):

      find /opt/lampp/htdocs -type f -exec chmod 644 {} \;