Flyt /home til ny diskpartition

Hvis du logger ud af din normal bruger, smutter over i en VT hvor du logger ind som root bruger du ikke nogle filer i /home.

Mount så bare din partition og kopier indholdet af home over på den. Ændre /etc/fstab så du får mountet din partition som /home og gem den. Så ville det nok være en god ide at omdøbe mappen /home på din rod partition så filerne stadig er der hvis noget skulle kikse.

Der efter burde du bare kunne køre mount /home og logge ind som normalt

Jeg ville gøre sådan her som root:

1. Tilføj den nye home-partition til din /etc/fstab
2. Mount den nye partition under /mnt/tmp
3. Kør kommandoen: rsync -avP /home/ /mnt/tmp/
4. Flyt /home til /oldhome og opret ny /home
5. Genstart.
6. Konstater at alt er som det skal være og slet /oldhome

Tak for inspirationen til jer begge.

Brugte kommandoen cp -ax til kopiere hele home til en midlertidig placering. rsync-kommandoen er sikkert ligeså velegnet til formålet.

Jeg har tilføjet den fjerde linje til /etc/fstab:

UUID=xx..x /boot ext3 defaults 1 2
UUID=xx..x / ext4 defaults 1 1
UUID=xx...x swap swap defaults 0 0
/dev/sda4 /home ext4 defaults 1 3

Og flytningen af /home ser ud til at virke efter hensigten med undtagelse af en enkelt detalje:

Efterfølgende har jeg (af helt andre årsager) skiftet bruger-ID på min bruger. Dvs. jeg har rettet nummeret i /etc/passwd og /etc/group og slutteligt skiftet uid/gid rekursivt for hele /home/bruger biblioteket.

Nu er mit problem at når jeg starter en terminal fra GNOME, så starter den i root "/" (!). Hvis jeg efterfølgende skriver "cd", så skifter den som forventet til /home/bruger, men hvorfor mon den starter i root? Det er jo ikke verdens største problem, men stadig en indikation af at et-eller-andet ikke er som det bør være. Jeg ved ikke om det er relateret, men i /var/log/messages finder jeg linjen: Jan 31 20:03:32 hostname gdm-simple-greeter[3078]: WARNING: Unable to query filesystem type for /home/bruger: Error getting filesystem info: Permission denied.

Nogen ideer om, hvad der kan være galt?

En ls -la i /home/bruger giver bl.a.

d?????????? ? ? ? ? ? .gvfs


Grimt! Hvordan fa'en fixer jeg det?

#3
Da du skiftede uid+gid gjorde du det også på selve mappe /home/bruger?

chmod bruger:grupper /home/bruger -Rv

#4
Hvad giver den kommando, hvis du kører den som root?

Hvis du skifte ejerskab på alle filer der tilhørte din gamle uid, så kan du gøre sådan her som root:


find / -uid $OLD_UID -exec chown $NEW_UID '{}' \;
find / -gid $OLD_GID -exec chgrp $NEW_GID '{}' \;

Indsæt selv de rigtige værdier :)

Jeg vil dog anbefale at teste det på en anden mappe end / først :)

EDIT: Rettede lige kommandoerne så de rent faktisk virker.

#6
Jeg finder det ret bekymrende at den giver samme resultat som root.

Jeg villle nok umounte filsystemet og kører en fsck på det.

#10
Jeg kører normalt med den fsck der passer til filsystemet uden særlige parametre:

fsck.ext4 /dev/sdaX

Så stiller den spørgsmål, hvis den finder noget. Du kan også hvis du stoler på den gør det rigtigt give den -p, så løser den problemer selv. Personligt foretrækker jeg at se hvad den laver, selvom jeg stoler på den.

#9
Ahh, jeg tror jeg er med. .gvfs er noget fuse-relateret og som der står i tråden du linkede til så kan kun der der mounter noget med fuse se det.

Som den bruger der ejer den home, hvad får du med ls -la .gvfs? Så kan du måske unmounte den manuelt med
fusermount -u .gvfs

Hvis den er optaget, så prøv:
fuseermount -z -u .gvfs

fsck forløb problemfrit og uden anmærkninger.

Ad omveje fik jeg efterfølgende forvildet mig ind i SElinux loggen (titlen siger "setroubleshoot browser"). Der fandt jeg flg. interessante meddelelse:

Summary
SELinux is preventing access to files with the label, file_t.

Detailed Description
SELinux permission checks on files labeled file_t are being denied. file_t is the context the SELinux kernel gives to files that do not have a label. This indicates a serious labeling problem. No files on an SELinux box should ever be labeled file_t. If you have just added a new disk drive to the system you can relabel it using the restorecon command. Otherwise you should relabel the entire files system.

Allowing Access
You can execute the following command as root to relabel your computer system: "touch /.autorelabel; reboot"

Additional Information
Source Context:  system_u:system_r:xdm_t:s0-s0:c0.c1023Target Context:  system_u:object_r:file_t:s0T
....


Jeg forstår ikke meget af det, men prøvede med "touch /.autorelabel; reboot". Det resultaterede i noget relabelling under boot, men nu er problemet til gengæld væk (!)

Tak for sparring :)