![]() Registered Member ![]()
|
I'm having a problem correctly mounting an ext3 partition on an external harddrive in a Neon live session.
The external drive is a gpt disk, with one HFS+ partition (holding Mac Time Machine backups), one ext3 partition (holding backups from my current Linux Mint 18.3 XFCE system and other data), and an EFI partition (I don't recally making it, so it must be something Mac OS X did). The version of Neon I used was 5.12.3. When I plug in the drive, both partitions (the HFS+ and ext3) can be mounted, and I can enter the HFS+ partition and view its contents via Dolphin or the command line without additional work. On the other hand, Dolphin won't enter the ext3 partition (I get a red error banner saying "could not enter /media/neon/Toshibackup" at the top the Dolphin window). I also can't cd into the directory nor can I list its contents, unless I run those commands as sudo or become the superuser. When I checked the properties of Toshibackup, it says that the user and group are 1000, while the user and group of the live session user are both 'neon'. I later ran cat on /etc/passwd and found that the uid for the user Neon is 999. I tried plugging in another disk that's entirely formatted as fat, and it gets mounted with the correct permissions and I can use it normally. Does anyone know why my ext3 partition won't mount with the correct permissions? I use it mainly with Linux Mint 18.3, and it mounts fine there. |
![]() Registered Member ![]()
|
So I did some researching and I think I have an idea of why my Toshibackup partition wasn't mounting with the right permissions but the FAT32 disk was. I looked up the uid & gid of my user on my Mint system, and they're 1000, same as the partition, so of course it would mount correctly there. So, it looks like an issue of mismatched permissions leading to the Neon live user only being able to use the partition as root. But then, why did the FAT32 disk not need extra intervention?
Well, it turns out FAT filesystems don't do POSIX file permissions. So I guess Neon was just mounting that disk with the permissions necessary for the current user (Neon) to use it directly without becoming root. The only way to really test this is to create an additional user in the live session with an id of 1000 and see what happens, but for now I'm satisfied with what I know. Tl;dr: the mounting issue is likely because I didn't fully understand how file systems work. |
Registered users: Bing [Bot], Google [Bot], Yahoo [Bot]