this post was submitted on 29 Sep 2024
37 points (95.1% liked)

Linux

48634 readers
1587 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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!

top 21 comments
sorted by: hot top controversial new old
[–] RmDebArc_5 20 points 2 months ago* (last edited 2 months ago) (2 children)

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

[–] [email protected] 6 points 2 months ago (3 children)

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 7 points 2 months ago (1 children)

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.

[–] [email protected] 1 points 2 months 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

[–] [email protected] 3 points 2 months 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

[–] [email protected] 2 points 2 months ago (1 children)

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)

[–] [email protected] 2 points 2 months ago (1 children)

Thank you, worked like a charm.

[–] [email protected] 2 points 2 months ago
[–] [email protected] 0 points 2 months ago

I would advise against that. Udisks2 should mount writable always.

[–] HumanPerson 6 points 2 months ago* (last edited 2 months ago) (1 children)

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 1 points 2 months 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.

[–] wildbus8979 3 points 2 months ago* (last edited 2 months ago) (2 children)

sudo chown -R youruser:youruser /path/to/mountpoint

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.

[–] [email protected] 1 points 2 months ago (2 children)

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.

[–] [email protected] 2 points 2 months 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.

[–] wildbus8979 1 points 2 months ago

You need the mount point not the device. Probably something like /media/Files

[–] FigMcLargeHuge 1 points 2 months 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 .

[–] [email protected] 2 points 2 months ago (1 children)

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)

[–] [email protected] 1 points 2 months ago

Will look into this if @[email protected] 's suggestion doesn't work.

[–] [email protected] 2 points 2 months ago (1 children)

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.

[–] [email protected] 2 points 2 months ago
[–] [email protected] 1 points 2 months ago

Use udisksctl mount and not the old mount command. This should work. No need to change ownership.