How to Change with CLI the mountpoint of /home in Fedora Silverblue 34

[mahdiaqallal]

@computersavvy and @guiltydoggy

Thanks really both for your help. Maybe a reminder of my first post in this thread:

The lsblk -f and /etc/fstab of my INITIAL system - which is created from a standard Fedora Silverblue install - without any customization (using Anaconda and automatic partitioning)

@mahdiaqallal

$ lsblk -f /dev/sda
 NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 vfat FAT32 A623-F1E3 590,3M 1% /boot/efi
├─sda2 ext4 1.0 2ddd824c-df0f-4e14-afc3-e93c42ab0dfe 839,3M 7% /boot
└─sda3 btrfs fedora_fedora 906b5870-a232-40e8-a1b0-e548f77cc69b 6,3G 81% /var/home

You can assess that /dev/sda3 is mounted to /var/home and not /home , so this is standard issue for Silverblue and I’ve check it with constancy, many new installs over.

Furthermore as requested by @guiltydoggy :

$ ls -la /home
lrwxrwxrwx. 3 root root 8 10 août   2021 /home -> var/home
$ ls -la /home/
total 0
drwxr-xr-x. 1 root         root          24 10 août   2021 .
drwxr-xr-x. 1 root         root         262 14 mars  20:49 ..
drwx------. 1 mahdiaqallal mahdiaqallal 354  9 avril 17:44 mahdiaqallal
$ 

tail -6 /etc/fstab
#
UUID=75a22715-dae3-4865-855a-d825b988c892 /                       btrfs   subvol=root,compress=zstd:1 0 0
UUID=caf6bd1f-c66b-4887-b5c7-f086c96ed899 /boot                   ext4    defaults        1 2
UUID=D48D-5DFE                            /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=75a22715-dae3-4865-855a-d825b988c892 /home                   btrfs   subvol=home,compress=zstd:1 0 0
$

@computersavvy

I think the OP may have an error in his fstab by mounting directly to /var/home. It likely should be similar to yours and be mounted to /home while allowing the system to handle the symlink redirect. I have no system on which to test that theory though.

I’have already tried this both ways as specified in my earlier response:

@mahdiaqallal

By the way assigning to the btrfs subvolume dedicated to /home either with the mountpoint /home or /var/home in /etc/fstab produces the same result: Fedora Silverblue does all the right symlinks necessery [in either situation]

In either case the drive containing the /home subvolume is mounted by the system and recognized as $HOME :

@mahdiaqallal

bash-5.1$ echo $HOME
/var/home/mahdiaqallal

@guiltydoggy

Can you also post your output of lsblk -f ? Just to verify the correct UUID in the fstab.

Please see my earlier response:

@mahdiaqallal

$ sudo lsblk -f  /dev/sdc /dev/sdb
NAME   FSTYPE FSVER LABEL         UUID                                 FSAVAIL FSUSE% MOUNTPOINT                            
sdb                                                                                                                          
├─sdb1 vfat   FAT32               DEEB-CDFE                                                                                 
├─sdb2 ext4   1.0                 d675c5b4-a45d-4529-b3c2-f6dc51e81e84                                                      
├─sdb3 btrfs        fedora_fedora 4ec9d406-41fb-4760-828b-35f1565ae5fc    8,4G    86% /run/media/mahdiaqallal/fedora_fedora 
sdc    btrfs        HOMETEST      7e81da8e-7058-44af-8496-695540dd8694    6,9G     1% /run/media/mahdiaqallal/HOMETEST

As you can see UUID for 7e81da8e-7058-44af-8496-695540dd8694 on /dev/sdc (which is where I want /home to be) is indeed correctly pointed in /etc/fstab (see above the result of tail -6 /etc/fstab)

So everything seems to be fine thanks to the steps and hints by you guys @guiltydoggy @computersavvy (and @siosm for his contribution in there ):

@mahdiaqallal

When I update the /etc/fstab , having created the relevant btrfs subvolume associated to /home and with mountpoint (/var)/home, at reboot, everything seems fine: Files and folders are where they are expected to be. Either mountpoints in /etc/fstab work the same : /var/home or /home

The two odd errors reported earlier make me wanting to be sure everything is indeed the way it should be.

• In command line : this odd comment

@mahdiaqallal

fedora login: mahdiaqallal
Password:
Last login: Tue Apr 5 19:25:57 on tty3
– mahdiaqallal: /var/home/mahdiaqallal: change directory failed: No such file or directory
Logging in with home = “/”
Welcome to Fedora Silverblue. This terminal is running on the
host system. You may want to try out the Toolbox for a directly
mutable environment that allows package installation with DNF.

For more information, see the documentation.

mkdir: impossible to create folder ’ /var/home/mahdiaqallal ’ : Permission denied’
touch: impossible to touch ‘/var/home/mahdiaqallal/.config/toolbox/host-welcome–shown:’ No file or folder exists

Beside this comment I can in command line access all folders and files as if there were no error.

• In GNOME user interface at reboot I get the correct Gnome Display Manager asking for logging in [with user mahdiaqallal] but then at Gnome main screen the Gnome Tour as if it what the first boot ever…

I really do not understand why…

[guiltydoggy (Yosuke)]

I am running out of ideas. Here are a few more things though:

@mahdiaqallal

You can assess that /dev/sda3 is mounted to /var/home and not /home , so this is standard issue for Silverblue and I’ve check it with constancy, many new installs over.

I just installed Silverblue 35 in a VM a couple days ago, and the fstab mounts to /home. But maybe this was different in Silverblue 34 - which I don’t have. But as you have tested both, I don’t think it is the issue anymore.

Silverblue 35 screenshot

@mahdiaqallal

$ sudo lsblk -f  /dev/sdc /dev/sdb
NAME   FSTYPE FSVER LABEL         UUID                                 FSAVAIL FSUSE% MOUNTPOINT                            
sdb                                                                                                                          
├─sdb1 vfat   FAT32               DEEB-CDFE                                                                                 
├─sdb2 ext4   1.0                 d675c5b4-a45d-4529-b3c2-f6dc51e81e84                                                      
├─sdb3 btrfs        fedora_fedora 4ec9d406-41fb-4760-828b-35f1565ae5fc    8,4G    86% /run/media/mahdiaqallal/fedora_fedora 
sdc    btrfs        HOMETEST      7e81da8e-7058-44af-8496-695540dd8694    6,9G     1% /run/media/mahdiaqallal/HOMETEST

This is interesting to me. You don’t seem to have a partition (sdc1) on your sdc block device. I think this is what you should try next. Delete and create a new partition map on the drive, and then create a new partition (Linux Filesystem). Then format that partition (sdc1) as btrfs. Then create the new “home” subvolume on that partition.

[guiltydoggy (Yosuke)]

I tried myself in my Silverblue 35 VM. I’m also seeing this issue:

I don’t have any ideas right now, but I’ll try to investigate later when I have some more time.

[computersavvy (Jeff V)]

@mahdiaqallal

• In GNOME user interface at reboot I get the correct Gnome Display Manager asking for logging in [with user mahdiaqallal] but then at Gnome main screen the Gnome Tour as if it what the first boot ever…

This would be because the new file system did not have the proper info to tell the system you had already logged in previously.
At login it starts gnome-tour unless you have previously logged in and the file ~/.config/gnome-initial-setup-done already exists. That file seems to be created whenever a new user is first logged in and the initial setup process runs. (gnome-tour ?)

[guiltydoggy (Yosuke)]

@mahdiaqallal

• In command line : this odd comment

@mahdiaqallal

fedora login: mahdiaqallal

Password:
Last login: Tue Apr 5 19:25:57 on tty3
– mahdiaqallal: /var/home/mahdiaqallal: change directory failed: No such file or directory
Logging in with home = “/”
Welcome to Fedora Silverblue. This terminal is running on the
host system. You may want to try out the Toolbox for a directly
mutable environment that allows package installation with DNF.

For more information, see the documentation.

mkdir: impossible to create folder ’ /var/home/mahdiaqallal ’ : Permission denied’
touch: impossible to touch ‘/var/home/mahdiaqallal/.config/toolbox/host-welcome–shown:’ No file or folder exists

Beside this comment I can in command line access all folders and files as if there were no error.

• In GNOME user interface at reboot I get the correct Gnome Display Manager asking for logging in [with user mahdiaqallal] but then at Gnome main screen the Gnome Tour as if it what the first boot ever…

I really do not understand why…

I think I’ve figured this out. It’s an SELinux issue. When we created the new /home on the new drive, the SELinux context was not set to indicate that this was to be used as a home directory.

You can see here that my new home directory on the new drive I created has an “unlabeled_t” context. In comparison, I’ve mounted the original home directory and it shows the correct context below that line: “user_home_dir_t”.

Screenshot from booting into a Live session and mounting the main and secondary drives for comparison:

I’m far from an expert on SELinux issues, but I found this Q&A that I believe fixes the issue. Booting back into the Silverblue system, I executed:

sudo semanage fcontext -a -e /home /var/home
sudo restorecon -vR /var/home

After which I logged out and logged back in through TTY and that error no longer appeared for me. Again, I’m not very knowledgeable on SELinux at all, so although this worked for me in my VM, you might want to wait to see if anybody here tells you this is a dumb thing to do or something before trying it on your system.

Edit: Here is a screenshot, going back into a Live session and re-mounting the secondary drive and querying the home directory - it shows the correct context for the home directory.

[computersavvy (Jeff V)]

That was the very thing I would have suggested when you said that it was an selinux issue.

If selinux is active and in enforcing mode then the users home directory must have the proper context and only by using restorecon can you reset everything the way the system expects it to be.

I recently encountered a similar error when something with selinux was modified but the update failed to run that exact command and some parts of the tree were left with the older context that interfered with the updated policies. The ‘sudo restorecon -vR /’ command fixed everything across the entire system for me.