Allow users access a 2nd disk added to fedora 35 box

Hi, I added a 2nd disk to my F35 VM, opened a session as root, formatted and mounted it with the following options

when I open a session with my user (who is a sudor as well) I get the following error

What is missing here to be able to access the 2nd disk? Thanks

What’s the output of ls -la /mnt/salam? Looks like you don’t have permissions to read that directory.

Here vis the output of the command

[salam@salamlinux ~]$ sudo ls -la /mnt/salam
[sudo] password for salam:
total 12
drwxr-xr-x 3 root root 4096 Apr 12 13:47 .
drwxr-xr-x. 3 root root 4096 Apr 12 13:47 …
drwx------ 3 root root 4096 Apr 12 12:01 data

Looks like only the root user has access to the data directory. So you can do sudo chmod 777 /mnt/salam/data to give everyone read/write access to data. Or do a chown to change the owner of data from root to your username.

While that may be reasonable for some, it is not a good suggestion for everyone. You note that the other directories in that location are 755 and general practice is to never use 777 for permissions but use 755 instead.

If the OP wants access to that directory for his own user it would be better to chown the directory and not change the permissions as sweepingly as 777 would do. In general, I cannot think of a single location in the entire file system that has or needs 777 permissions. I always think security with every suggestion made.

This would render that directory visible, but not writable - likely not what OP would want for a newly formatted disk they are trying to access. And hence why I said if they want “to give everyone read/write access”.

Also, files/directories created within data by the user will have proper permissions (644/755 respectively). It will ultimately depend on how OP wants this data disk to be used and by whom.

Which I also suggested, but failed to expound on the implications - which are that it would make this directory read/writeable to themselves only. Which is fine and more secure if they are the only person this new drive is meant to serve.

In Fedora the sudo group is wheel. When you want to use it with root and sudo user you might change chown root:wheel and chmod 775 for data so you have full access for root and sudo.

So many thanks for both of you, great explanation, as this disk is for my own use, I changed the owner and I was able to create directories. However, I have another question, I need my home directory be moved always to this disk. So instead of having home at
home/salam
on 1st disk
I need something like
Data/salam
Why because 1st disk is almost full and would like to make more free space on 1st disk as home/salam is too big

Easiest would be to make a subdirectory of your home directory such as /home/salam/Data then mount the second drive at that location. Once that is done then you could move anything already in your home directory to the new drive and free up space you have already used.

To me that seems easier than fully moving everything.

However, it is easy to use rsync and copy everything from your home directory to the data drive, make a changed entry in /etc/fstab to mount the new drive at /home, then delete everything in the old /home/salam. Once that is done a reboot will have your home directory on the new drive.

It would be easiest and safest to do the above while booted from a live usb so nothing in your home directory is being altered while it is copied and relocated.

Hi Jeff, I think 2nd option is better. However, I searched etc directory, no fstab file there

You appear to be using fedora 35. I can assure you that there is certainly a file /etc/fstab that exists there. The same file exists on almost every linux version on the planet.

1 Like

Sorry, my bad, I missed it. Just opened it now and it contains the following

/etc/fstab

Created by anaconda on Thu Jul 10 14:26:18 2014

Accessible filesystems, by reference, are maintained under ‘/dev/disk’

See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info

/dev/mapper/fedora-root / ext4 defaults 1 1
UUID=900921c6-9d99-4b18-9535-344bad16f848 /boot ext4 defaults 1 2
/dev/mapper/fedora-home /home ext4 defaults 1 2
/dev/mapper/fedora-swap swap swap defaults 0 0
/dev/disk/by-uuid/1fdf33f1-1218-4dea-a720-1b88d047e6bb /mnt/salam/data auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data 0 0

So directories inside /dev/mapper/ were created during installation. So how can I tell fedora 35 that

/dev/mapper/fedora-home /home

is not anymore the honme directory but it should be

/dev/disk/by-uuid/1fdf33f1-1218-4dea-a720-1b88d047e6bb

Should I copy first all contents from my current home/salam to the new disk to a directory named “home” as well then make the change in fstab?

You should log in on with a live usb boot and follow these steps (as root)

mount /dev/mapper/fedora-root /mnt
mount /dev/mapper/fedora-home /mnt/home
mount /dev/disk/by-uuid/1fdf33f1-1218-4dea-a720-1b88d047e6bb /mnt/mnt/salam/data
rsync -avh /mnt/home/  /mnt/mnt/salam/data/

Once all that has finished edit /mnt/etc/fstab and remove the line that starts with /dev/disk/by-uuid and replace it with UUID=1fdf33f1-1218-4dea-a720-1b88d047e6bb /home ext4 defaults 1 2
Also put a ‘#’ in front of the existing line that mounts /dev/mapper/fedora-home so it is commented out and does not take effect.

Once all that is done then reboot to the normal system and everything should be normal with your new disk mounted at /home and the way you want it.

For a final clean up after you are sure everything is correct you can delete all the data that was on the original /dev/mapper/fedora-home partition with a couple more steps.

mount /dev/mapper/fedora-home /mnt
ls /mnt    # this is to verify that it is what you expect
rm -rf /mnt/*
umount /mnt

These steps will empty out the data you previously had in that partition and free the space for other uses.

1 Like

Again so many thanks for your help. However, I started looking at liveusb but just figured out that Hyper-V on windows does not allow attaching a USB to the VM only CDs. I visited fedora docs on how to create a live CD, it is a little bit complicated. isn’t there a ready made CD that we can download and use?

The “DVD ISO” downloads available on Download Fedora Workstation will get you a file that you can burn on a DVD disc using any DVD burning software of your choice, or use the ISO image directly through Hyper-V as a bootable disc.

Hi Jeff, I followed your instrusctions using the fedora live iso image, I was able to modify the fstab as follows

but when I rebooted, it refused to reboot and got
fstab_002

so I booted again with the live fedora and reverted back the fstab as it was and I was able to reboot and access my fedora

/etc/fstab

Created by anaconda on Thu Jul 10 14:26:18 2014

Accessible filesystems, by reference, are maintained under ‘/dev/disk’

See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info

/dev/mapper/fedora-root / ext4 defaults 1 1
UUID=900921c6-9d99-4b18-9535-344bad16f848 /boot ext4 defaults 1 2
/dev/mapper/fedora-home /home ext4 defaults 1 2
/dev/mapper/fedora-swap swap swap defaults 0 0
/dev/disk/by-uuid/1fdf33f1-1218-4dea-a720-1b88d047e6bb /mnt/salam/data auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data 0 0

UUID=1fdf33f1-1218-4dea-a720-1b88d047e6bb /home ext4 defaults 1 2

LABEL=Data /mnt/salam/Data auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data 0 0

You must make certain that mounting that partition at /home works before you boot with the fstab that way.

These steps should enable the test.

boot to live usb
mount /dev/mapper/fedora-root /mnt
mount /dev/disk/by-uuid/900921c6-9d99-4b18-9535-344bad16f848 /mnt/boot
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -o bind /run /mnt/run
chroot /mnt

At this point you should be as root in your actual system but without mounting /home

The next step is to test if you can mount the drive at /home
mount /dev/disk/by-uuid/1fdf33f1-1218-4dea-a720-1b88d047e6bb /home and that its contents are as expected.
ls /home should show your users home directory (salam) with proper ownership.

If these steps are successful then you can edit /etc/fstab as before so it reads

/dev/mapper/fedora-root / ext4 defaults 1 1
UUID=900921c6-9d99-4b18-9535-344bad16f848 /boot ext4 defaults 1 2
# /dev/mapper/fedora-home /home ext4 defaults 1 2
/dev/mapper/fedora-swap swap swap defaults 0 0
# /dev/disk/by-uuid/1fdf33f1-1218-4dea-a720-1b88d047e6bb /mnt/salam/data auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data 0 0

UUID=1fdf33f1-1218-4dea-a720-1b88d047e6bb /home ext4 defaults 1 2

# LABEL=Data /mnt/salam/Data auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data 0 0

Note that the 2 lines beginning with LABEL and /dev/disk/by-uuid are duplicates in action and will cause conflicts if not commented out. In fact if they were not commented out when you last tried it they may have caused the error.

Once this edit has been done then do

umount /home
mount -a

If both those commands work and mount shows that the drive is mounted properly then you can do exit to get out of the chroot mode then reboot and it should now work properly

If your device is using btrfs file system, you can add the second storage on the fly with 'btrfs device add … ’ likewise you add storage on the fly with LVM2. It’s easy with everything in one partition, more complicated otherwise as you add partition by partition. Useful in the early days of MULTICS considering hardware used, today a bit overblown. You don’t need to dig in to details as everything is attached to the initial drive, the rest is booted mounting the file system.