External disk | UID 1000 access only [solved]

[axrusar]

Guys..
I have an external SSD disk i use for my backups. It is encrypted with LUKS, so i have to enter the passphrase to mount it.
Yesterday i was helping a friend with her BSOD windows laptop and set her up with Mint 21
So i wanted to use my external disk to backup her data first, i booted the live mint session to access her windows partition, plugged in my external drive, typed the passphrase and ops!
Permission denied to access the mounted drive partition.
So i take a look at the permissions, and the partition is assigned to UID 1000. I check the id of the live session mint user and it is 999.
I ended up using other external flash drives feeling like an idiot scratching my head....
Now that i am testing, if i create a new user in the mint live session, it gets UID 1000 and i am able to mount and use the drive with no issues.
No big deal, but i would like to know, if there is a way to setup a partition so it is accessible to any UID, being an external drive, i might need to plug it on a different system in the future, and who knows if ID 1000 will be available then.
I think i used the mint disk utility to format the partition as ext4 with luks. so it is set with 700 permissions.

[xenopeek]

so it is set with 700 permissions.

Maybe change it to 777? Only somebody that knows the LUKS passphrase can mount it anyway.

[axrusar]

Yes.
I tested with a spare USB flash drive. Created a LUKS partition and chmod 777 it. Now other users in the system can write to it.
Although, of course it keeps the linux file permission structure.
So if my laptop hard disk ever fails i guess i will have to chown the whole backup drive folders and subfolders to the new user to get access to the files right?
Should i use NTFS instead? I use luckybackup and copy my home folder to the external disk.

[rene]

Should i use NTFS instead?

No, never. And no, you will not have to chown anything just to "get access".

UNIX-permissions are 3 times 3 bits rwx for respectively the file/directory's user, members of its group, and others, with a 1 meaning said r, w or x right is granted, 0 not.

Code: Select all

r w x
0 0 0 = 0
0 0 1 = 1
0 1 0 = 2
0 1 1 = 3
1 0 0 = 4
1 0 1 = 5
1 1 0 = 6
1 1 1 = 7

Specifically then 7 means full rights for that specific category of user, and 777 full rights for all 3 such categories -- which is basically to say you disable UNIX-pemissions: every user has every right (you may prefer symbolic modes; 777 can in the context of for example chmod also be described more mnemonically as ugo=rwx; see man chmod).

[axrusar]

Thank you guys.
I did a test on the USB flash drive. The root is set with 777. I copied some files and mounted the drive in a different local account. So even tho the copied files have a padlock and i am unable to modify them, i do get access to copy them to the computer and permissions get updated locally of course, so all good.
That means if i ever need to restore my computer from the backup on a fresh installed system, i will have to format the external drive and start over again mirroring the data.

[rene]

That means if i ever need to restore my computer from the backup on a fresh installed system, i will have to format the external drive and start over again mirroring the data.

Not so sure about that part. Had this conversation a little while also here on the forum: it's vital to the understanding of UNIX-permissions that -- on a filesystem type that in fact supports UNIX permissions, i.e., not NTFS or (ex)FAT -- UNIX-permissions are properties of individual filesystem objects (a file, a directory, a device node, ...) and not of a complete filesystem or partition.

Here this is to say that the 777 that "the root is set with" means exactly that: that everyone has read, write and execute (search, since it's a directory) access to that root directory and then not necessarily to any file or subsubdirectory residing in subdirectories of that root directory. You'd set everything on the filesystem 777 with after mounting sudo chmod -R 777 /the/mount/point/. That is, by applying the 777 recursively.

Last time I failed to communicate that the above is not a detail and I sort of hope it works this time: it's only damn Microsoft with its filesystems not supporting UNIX-permissions in the first place that again muddies this, what with those being crammed into the UNIX-mold by Linux mounting them with filesystem-wide "pretend credentials". For real filesystems you'll never have an issue understanding things as soon as you have the correct mental picture of UNIX-credentials being per file/directory -- even if said file/directory is a filesystem's root-directory.

Anyways....