Automount HDD for all users

Forewarning, I am a newb and know just enough to screw up my system really bad. :grin:
I have a second HDD in my desktop for data. It mounts and I can use it with no problem. It also mounts for other users, but their editing ability is limited. I noticed users other than myself aren’t allowed to create a folder on the data drive. How do I correct that please? Is it a mounting issue, a permissions issue, or something else?
Thanks for your help.

You say “it mounts” and I know that many people say so. But in fact disks do not get mounted. File systems get mounted. And file systems may be direct on the disk, but most of the time they are on a partition of a disk. So it is in fact unclear what mounts.

Then the type of a mounted file system is important. Many problems arise when the file system is not a native Linux one.

Then, the mount point is important. Because you rightfully think that permissions might have to do something with it, the ownership and permissions of the mount point (and the path to the mount point)are important. That is not restricted to a mount point of course, that is true for every directory.

Als you do not explain anything about the mount action. Is it done on boot (using an /etc/fstab entry), is it done later manually by root, is it done using the desktop features?

So please provide information like

fdisk -l
lsblk -f
cat /etc/fstab
mount
ls -l <the-mount-point>

Thank you very much for your help.
The HDD in question is UUID=c11e498d-3c99-42c3-8ae3-23c2dc54c96c
christopher has full access to the partition
Kathy has limited access to the partition
The information you requested is below

christopher-asusdesktop:/home/christopher # fdisk -l
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: WDC WD2500BEVT-7
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0A5EC9B8-C218-415D-A974-7186ED7035BB

Device Start End Sectors Size Type
/dev/sda1 2048 1023999 1021952 499M Windows recovery environment
/dev/sda2 1024000 1228799 204800 100M EFI System
/dev/sda3 1228800 1261567 32768 16M Microsoft reserved
/dev/sda4 1261568 488396799 487135232 232.3G Microsoft basic data

Disk /dev/sdb: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC WD5000LPLX-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x8ffa11af

Device Boot Start End Sectors Size Id Type
/dev/sdb4 206848 976771071 976564224 465.7G 5 Extended
/dev/sdb5 208896 976769023 976560128 465.7G 83 Linux

Disk /dev/nvme0n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: HP SSD EX900 500GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A607F25C-278D-4045-BEB4-2BD22DF11EED

Device Start End Sectors Size Type
/dev/nvme0n1p1 4096 618495 614400 300M EFI System
/dev/nvme0n1p2 618496 976768064 976149569 465.5G Linux filesystem

Disk /dev/zram0: 15.52 GiB, 16667549696 bytes, 4069226 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher # lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 ntfs Recovery 2CC0F30FC0F2DDD0
├─sda2 vfat FAT32 22F4-1313
├─sda3
└─sda4 ntfs EACEF5F5CEF5B9C1
sdb
├─sdb4
└─sdb5 ext4 1.0 LinuxData c11e498d-3c99-42c3-8ae3-23c2dc54c96c 306.9G 33% /home/data
sr0
zram0 [SWAP]
nvme0n1
├─nvme0n1p1 vfat FAT32 NO_LABEL 0B45-3480 295.7M 1% /boot/efi
└─nvme0n1p2 btrfs 006646ba-934c-4072-b66d-652138c52de5 433.8G 7% /home
/root
/var
/.snapshots
/
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher # cat /etc/fstab

/etc/fstab: static file system information.

Use ‘blkid’ to print the universally unique identifier for a device; this may

be used with UUID= as a more robust way to name devices that works even if

disks are added and removed. See fstab(5).

UUID=0B45-3480 /boot/efi vfat umask=0077 0 2
UUID=006646ba-934c-4072-b66d-652138c52de5 / btrfs defaults,noatime,space_cache=v2,compress=zstd,discard=async,ssd 0 0
UUID=006646ba-934c-4072-b66d-652138c52de5 /.snapshots btrfs subvol=/.snapshots,defaults,noatime,space_cache=v2,compress=zstd,discard=async,ssd 0 0
UUID=006646ba-934c-4072-b66d-652138c52de5 /home btrfs subvol=/home,defaults,noatime,space_cache=v2,compress=zstd,discard=async,ssd 0 0
UUID=006646ba-934c-4072-b66d-652138c52de5 /root btrfs subvol=/root,defaults,noatime,space_cache=v2,compress=zstd,discard=async,ssd 0 0
UUID=006646ba-934c-4072-b66d-652138c52de5 /var btrfs subvol=/var,defaults,noatime,space_cache=v2,compress=zstd,discard=async,ssd 0 0
UUID=c11e498d-3c99-42c3-8ae3-23c2dc54c96c /home/data ext4 auto,user,rw 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher # mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=4096k,nr_inodes=2028341,mode=755,inode64)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=3255384k,nr_inodes=819200,mode=755,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-vconsole-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p2 on / type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=23917)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /tmp type tmpfs (rw,noatime,inode64)
ramfs on /run/credentials/systemd-sysctl.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p2 on /.snapshots type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=260,subvol=/.snapshots)
/dev/nvme0n1p2 on /var type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=259,subvol=/var)
/dev/nvme0n1p2 on /root type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/root)
/dev/nvme0n1p2 on /home type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/home)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sdb5 on /home/data type ext4 (rw,nosuid,nodev,noexec,relatime,user)
ramfs on /run/credentials/systemd-tmpfiles-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1627688k,nr_inodes=406922,mode=700,uid=1000,gid=1003,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1003)
pcloud on /tmp/.mount_pcloudJwVhUm type fuse.pcloud (ro,nosuid,nodev,relatime,user_id=1000,group_id=1003)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1003)
pCloud.fs on /home/christopher/pCloudDrive type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1003)
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher #
christopher-asusdesktop:/home/christopher # ls -l /home/data
total 32
drwxrwxr-x 28 christopher users 4096 Jul 17 21:33 christopher
drwxr-xr-x 9 kathy kathy 4096 Jul 16 20:15 Kathy
drwxrwxr-x 2 christopher users 16384 Sep 12 2021 lost+found
drwxrwxr-x 9 christopher users 4096 Jul 8 15:02 timeshift
drwx------ 4 christopher christopher 4096 Jul 16 16:22 .Trash-1000
christopher-asusdesktop:/home/christopher #

Oh boy, is this unreadable. Please always post computer text with fixed format. Select the computer text part and then hit the </> button in the tool bar of the post editor. Or, alternatively, type first three “backquote” characters on a line, the paste your computer text below it end again thre “backquote” characters on the next line.

I will try to study all you posted, but this part

already shows some directories/files are owned by christopher of group users and others are owned by kathy of group kathy. And there is also the combination christopher with group christopher.
This throws up the question, how is this supposed to be organised in your system? And maybe, sorry for the question, do you know anything about users, groups and file permissions?

What is missing (sorry for not asking the first time), is about the mount point itself. To make it complete repeat the command with one more option

ls -ls /home/data

This has BTW all NOTHING to do with the mounting of a file system on /home/data. Ownership and permissions work always regardless if something is mounted on a mount point or if it is in the same file system.

1 Like

Apart from the above, now knowing that this is about mount point /home/data, I filtered your unreadable mass.

This is all about the ext4 file system that is on /dev/sdb5 and that is mounted on /home/data. This is defined as such in/etc/fstab and thus will be mounted on boot.

That is all fine and OK and has nothing to do with your problem. Your problem is with using different users (and different groups) that own the files and those users have set restrictions on those files to prtoect them from other users. And of course when christoffer does not allow other users to read and/or wrire to a file he owns, kathy will not be able. That is the nature of not allowing.

1 Like

Please take note of UNIX¼ users and groups – <https://wiki.archlinux.org/title/Users_and_groups>.

Please be aware of directory ownership and access rights – <https://wiki.archlinux.org/title/File_permissions_and_attributes>
And – <https://linuxhandbook.com/linux-file-permissions/>.
And – <https://www.digitalocean.com/community/tutorials/linux-permissions-basics-and-how-to-use-umask-on-a-vps>

The home folder of a USB drive will always revert to root.
If your files are in the base directory, all will be owned by root.

To circumvent this on a USB you should move all your field to a subdirectory and then set the permissions of that directory to the ones you want.

Include the group members for the specific directory or create a group.

You can use dolphin root in the menu to easily change permissions with a graphical frontend.
But don’t do this to easy for /home !
You can create a shared folder and give the permissions to the others users with a directory you own

/home/USERNAME/SHARE
create a folder for sharing under your name and then set the permissions with a right click as standard user

Sorry, but this is nonsense. It has nothing to do with USB (or any other connection type of the hardware). It has nothing to do with the fact that it is separate file system.

Unix/Linux has ONE directory tree starting at / (called the root).
The contents of that tree is build by mounting file systems. Each file system has his own root and that is then “connected” to a directory (called the mount point) in the tree as it exists at the moment of mounting.

I the following the “you” mentioned is the system manager or for short root.

The first file system that is mounted is called the root file system and it is mounted at /. From then on you can address files within that root file system starting a path string from /.

You can then mount another file system on a directory (every existing directory you want). From that moment you can address files within that second file system with a path starting with the path of the mount point.
It is e.g. often done to have a separate file system for /home. Thus the mount point is /home and all inside the file system is addressed with /home/.....
As a furthet example, when needed, you can then have a separate file system, that you want to add to the disk space of user musicloverbecause he asked you for this to put his music files on. What you could do (but the variations are endless) is let him create a directory /home/musiclover/music and then you mount a file system at that mount point. Because musiclover created the mount point, he is owner of it and it will have the same permissions as every directory he creates. Thus he can read/write music files in the file system as he likes addressing it as /home/musiclover/music/.....

For musiclover (and for all other users, including root, there is no difference if `~musiclover/music/ is a mount point of a separate file system or not. The same rules for ownership and permissions stay the same.

The whole idea behind mounting is that it hides the fact that there are different file systems involved. You can forget about it.

And when a mount point is owned by root:root, that is because it is created as such, most probably by root (may be done using a “partitioner”). But when the owner should be different, then root is responsibie to do the appropriate change (e.g. using chown).

So “The home folder of a USB drive will always revert to root” is untrue, it only is so when root does not fulfill his task properly and does sloppy system management.

Ah, sorry I might have mentally answered to the wrong question.

But I am using ext4 USB-drives and experienced above mentioned issues. So my solution to non FAT32/exFAT filesystems is always using a subdirectory and there giving the appropriate rights to it, saving me a LOT of headaches, walking between machines.
You might disagree to the description, as it is possibly not a USB-drive in which the issues appeared.

But also for NET install I experienced this if you install from ISO I never could install from the root directory of a USB-drive, I always needed to put it into a subdirectory and, in my case /ISO/ and gives the all attributes to the ISO and directory.

Sorry to have bothered you. I won’t do so again.

I do not understand that. This forums is for asking questions. and for getting answers. Maybe extensive answers, the leaning curve of Linux is steep.

Now, did you succeed in solving your problems of who is owner of what and who may access what?

Depends on how you mount it –

  • If you mount it by means of autofs (the systemd autofs.service) of fstab then, yes, you’re correct.
  • If however, you mount the USB device by means of FUSE then, the top directory of the device will be owned by the user who invoked the Filesystem in Userspace (FUSE) mount 


BTW – the top directory of a mounted device isn’t always a “home” directory but, it could be 


  • And, the top directory of a mounted device is ‘/’ for only one case –
    The mounted device is the system’s system disk 

    But, even then not really – there’re all the virtual (in memory) system directories in “/” – “sys”, “dev”, “run” and “proc” 


Ooops – a brain and fingers issue –

“/” isn’t a directory –

  • It’s a marker for the top of the system’s directory tree 


The bottom line is here: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html>

The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system.

Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.

Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability.


Yes, the user “root” can create files directly referenced by “/«filename»” and, those files will be located on the system’s system disk but, this is strongly discouraged due to the restraints specified in the Filesystem Hierarchy Standard (FHS) 


In the hope to shed more light on this, basically simple, subject, I prepared an USB memory stick with one partition and made an ext3 file system upon it. I gave the file system a volume label of HenMremov Then I put some files on the file system and made all (including the root of that file system) owned by user mgi with group users.
That was of course all done “as root”.

Then user henk created a directory with one file in it.

henk@boven:~/test> ls -la stick
total 8
drwxr-xr-x 2 henk wij 4096 Jul 20 19:37 .
drwxr-xr-x 9 henk wij 4096 Jul 20 19:43 ..
-rw-r--r-- 1 henk wij    0 Jul 20 19:37 nothing-mounted-here
henk@boven:~/test>

As we see the directory stick, that is to be used as mount point in our example, has one file with a name that warns us that there is nothing mounted on the mount point.

boven:~ # grep HenM /etc/fstab
LABEL=HenMremov         /home/henk/test/stick              ext3   nofail                0  0
boven:~ #

I think this is self explanatory, the nofail is because I do not want to hang at boot when the stick isn’t connected.

boven:~ # mount /home/henk/test/stick/
boven:~ #

The mount is done by root and that can be checked:

boven:~ # mount | grep stick
/dev/sdc1 on /home/henk/test/stick type ext3 (rw,relatime)
boven:~ #

Now, what sees henk?

henk@boven:~/test> ls -la stick
total 10492
drwxr-xr-x 6 mgi  users     4096 Jan  3  2020 .
drwxr-xr-x 9 henk wij       4096 Jul 20 19:43 ..
drwxrwxr-x 2 mgi  users     4096 Aug  6  2013 JordanBloemen
-rw-r--r-- 1 mgi  users 10690560 Jan  3  2020 gr.tar
drwx------ 2 mgi  users    16384 Jan 18  2010 lost+found
drwxr-xr-x 3 mgi  users     4096 Jun 12  2012 mgi
drwx------ 3 mgi  users     4096 Jun 12  2012 midrange
henk@boven:~/test>

He is now only owner of the parent directory test, but not anymore of stick. This because the root of HenMremov is now /home/henk/test/stick and is thus owned by mgi:users. Likewise the file nothing-mounted-here is not visible anymore. The whole of old stick is now invisible and covered by the contents of the ext3 file system HenMremov.

And that is what also happened when you say the the mount point “reverted to root”. It doesn’t. But what you mounted upon it is owned by root. When you change that, your problems are gone.

In this case, henk can of course do nothing:

henk@boven:~/test> chown henk:wij stick
chown: changing ownership of 'stick': Operation not permitted
henk@boven:~/test>

Neither can mgi:

mgi@boven:/home/henk/test> chown henk:wij stick
chown: changing ownership of 'stick': Operation not permitted
mgi@boven:/home/henk/test>

But root can:

boven:/home/henk/test/stick # cd ..
boven:/home/henk/test # chown -R henk:wij stick
boven:/home/henk/test #

And after that henk sees:

henk@boven:~/test> ls -la stick
total 10492
drwxr-xr-x 6 henk wij     4096 Jan  3  2020 .
drwxr-xr-x 9 henk wij     4096 Jul 20 19:43 ..
drwxrwxr-x 2 henk wij     4096 Aug  6  2013 JordanBloemen
-rw-r--r-- 1 henk wij 10690560 Jan  3  2020 gr.tar
drwx------ 2 henk wij    16384 Jan 18  2010 lost+found
drwxr-xr-x 3 henk wij     4096 Jun 12  2012 mgi
drwx------ 3 henk wij     4096 Jun 12  2012 midrange
henk@boven:~/test>

There is one thing wrong here!! lost+found should be owned by root:root, it is part of the housekeeping of the ext3 file system.

Hope this helps in understanding how a mounted file system overlays a mount point.

1 Like

And now you understand why it makes sense to move everything into a subdirectory and save yourself headaches from that behavior :grin:

Also if you use different machines. Lubuntu/Fedora/Tumbleweed back and forth.

Which is what the Filesystem Hierarchy Standard (FHS) recommends 
 :sunglasses: