Hello Linux Helpdesk. ;)

I use Fedora (currently 40), and have done for a while.

I always LUKS+Ext4 encrypt my local drive and decided to do the same to my external hard drive.

Last week I reinstalled Fedora 40 from a Bootable USB, but when I tried to access my files om my external drive it now gives me the error

You do not have permission to view the content of “Files”.

I’ve read online it’s due to me no longer being the “Owner” of the drive I was in my previous install of Fedora and now I’m a different user and apparently no users a part from Owner have any permissions on an EXT4+LUKS drive.

Is there any way to give myself permission to see the content again or did I bonk my backup? As a note, I DO have the correct Luks password, it shows me the name of the encrypted disk after decrypting, which is “Files”

Thank you in advance.

Edit: Thank you everybody, thanks to you I’ve been able to rescue my files. Y’all deserve a great day!

  • RmDebArc_5@sh.itjust.worksEnglish
    20·
    1 month ago

    Use chown to change ownership or chmod to change rights. The -R option makes them also change the permissions for all files and directories inside of the directory.

    sudo chown -R <username>:<usergroup>  /pathto/Files

    Arch man

    • drid@lemmy.mlOPEnglish
      6·
      1 month ago

      Another user suggests youruser:youruser and not usergroup, if usergroup would I just use the Owner group or?

      Thank you for your answer.

      • RmDebArc_5@sh.itjust.worksEnglish
        81·
        1 month ago

        I believe you can just do youruser: and chmod automatically uses the correct group. The other user is also technically correct as the usergroup is called the same as the user so both commands are the same.

        • electricprism@lemmy.ml
          1·
          1 month ago

          Typically the user group is identical to the username but not always. For example a name containing uppercase letters may be transformed to be all lowercase for the user but contain both cases in the group.

          Thus you should get the user group in scripting separate from $USER

      • boredsquirrel@slrpnk.net
        3·
        1 month ago

        Those are placeholders. Your user has a name and is in a group. No idea what that group is called like. For root it is root:root

      • harsh3466@lemmy.ml
        2·
        1 month ago

        youruser:youruser just means the user’s group. For instance, on my fedora 40 install, my user (bippy, just a silly name), is the username for my user, but also the name of the group that my user belongs to.

        So when I do a chown, I typically do chown -R bippy:bippy path/to/directory

        If you wanted to give permissions to a different group on your system, but also to your main user, you could do a chown -R bippy:wheel /path/to/directory (wheel is an example group name, which is similar to sudoers)

  • HumanPerson@sh.itjust.worksEnglish
    6·
    1 month ago

    this is a file permission issue, nothing to do with LUKS. The solution should be to access the files as root. You could use the command “Sudo chmod a+rwx /path/to/drive” to set completely accessible file permissions, which is not a best practice typically, but would be fine here since the drive’s encrypted.

    • lurch (he/him)@sh.itjust.works
      1·
      1 month ago

      root can always access them. it’s exactly for solving these kind of maintainance and repair tasks.

      btw don’t forget to make backups. repairing things can go sideways.

    • drid@lemmy.mlOPEnglish
      1·
      1 month ago

      Will try tomorrow when I get up.

      Would /dev/sda suffice as mounting point or?

      Haven’t set any permissions outside standard given ones by usage.

      Thanks for answering.

      • mlfh@lemmy.ml
        2·
        1 month ago

        /dev/sda is the whole raw disk - you typically don’t want to directly interact with /dev/sda, unless you are partitioning or overwriting it. There are a few layers between that device and the files:

        • raw disk - /dev/sda
        • disk partition - /dev/sda1
        • luks container - when unlocked, mapped to /dev/mapper/{name}
        • ext4 filesystem inside the luks container, mounted somewhere like /mnt, /media, etc

        You’ll need to find where that ext4 filesystem is mounted, and run the chown command on that. You can run lsblkand see a tree of the above hierarchy, with the ext4 filesystem’s mountpount shown in the right-hand column.

    • FigMcLargeHuge@sh.itjust.worksEnglish
      1·
      1 month ago

      Will make all the files in the path owned by you. Be careful if you have more complex permissions on there they will be lost.

      This is where ACL permissions would help. He could give his new id ACL permissions to the files and that wouldn’t mess with the current permissions.

      From the root/beginning subdir: sudo setfacl -R -m u:{replace with your new id}:rwx .

  • thisNotMyName@lemmy.world
    2·
    1 month ago

    You could try using bindfs to spoof the original user id and then chown the whole drive after successfull mounting (i’m a noob, just my understanding of the issue, don’t know if that’s really possible)

  • Hubi@feddit.org
    2·
    1 month ago

    Your files are not lost. You will be able to access them with your local root user, either through the command line or a GUI file explorer that supports actions as root.