Відновлення пошкодженого профілю користувача без втрати Desktop та Documents

February 8, 2026 • February 8, 2026 • Читання: 6 хв • Views: 0

Було корисно?

Ваш обліковий запис «працює» до моменту входу. Потім ви отримуєте порожній робочий стіл, цикл входу, відсутні Documents
або програми аварійно завершують роботу так, ніби змагаються у швидкому проходженні. Це не просто поганий день. Це день пошкодженого профілю.

Добра новина: у Linux «профіль» — це переважно файли: dotfiles, каталоги з налаштуваннями та власність/права доступу.
Ще краща новина: ваші Desktop і Documents зазвичай невинні свідки. Якщо перестати імпровізувати і дотримуватися плану,
можна відновити обліковий запис, не знищивши потрібні дані.

Що насправді означає «пошкоджений профіль» у Linux

У Linux «профіль користувача» — це не реєстр і не містична база даних. Це ваш домашній каталог плюс набір очікувань: UID володіє файлами,
shell може читати стартові скрипти, оточення робочого столу може записувати налаштування, а менеджер сесій може створювати тимчасові файли.

Коли люди кажуть «профіль пошкоджено», зазвичай мають на увазі одне (або кілька) з наступного:

Зміни власності/прав: ваш домашній каталог належить root або dotfiles недоступні для запису.
Тиск на диск: домашній розділ заповнений, вичерпано inode або перевищено квоту; сесії поводяться дивно.
Зламані налаштування: якийсь dotfile або каталог налаштувань викликає зависання shell/робочого столу при старті.
Помилки файлової системи: помилки метаданих ext4/XFS; перемонтовано в режимі лише для читання; помилки I/O.
Невідповідність міток безпеки: некоректні контексти SELinux; вхід працює, але програми не можуть читати/писати.
Несумісність UID: той самий імʼя користувача, але інший UID після відновлення; права не «перейшли» за файлами.

«Виправити» профіль означає відновити ці очікування, зберігши ~/Desktop та ~/Documents недоторканими.
Для цього потрібна дисципліна. Найшвидший шлях втратити дані — почати «чистку», видаляючи випадкові dot-папки тому, що якийсь пост у блозі так порадив.

Швидкий план діагностики (перший/другий/третій)

Коли поспіх, не вгадуйте. Тріажуйте так, ніби ви на виклику і не виспалися (так і є).

Перший: чи може система писати туди, де потрібно?

Чи заповнено / або /home?
Чи файлову систему перемонтовано в режимі лише для читання?
Чи користувач володіє своїм домашнім каталогом та ключовими підкаталогами?

Другий: чи це аварія входу/сесії через налаштування?

Перевірте журнали (journal) для сесії користувача.
Спробуйте увійти під новим тестовим користувачем на тому самому комп’ютері.
Спробуйте мінімальну shell-сесію (TTY) і подивіться, чи сам обліковий запис життєздатний.

Третій: чи сховище вам бреше?

Скануйте на помилки I/O, відновлення журналу ext4, аварійні зупинки XFS, попередження SMART.
Шукайте вичерпання inode і збої квот.
Перевірте узгодженість UID між резервними копіями/відновленнями.

Правило прийняття рішення: якщо бачите повний диск або перемонт у режимі read-only, перестаньте звинувачувати «пошкодження профілю» і спочатку виправляйте сховище.
Сесія робочого столу, яка не може нічого записати, поводитиметься як проклята.

Безпека насамперед: збережіть Desktop і Documents перед втручанням

Маєте лише один шанс не зробити гірше. Перед тим як «виправляти», зробіть snapshot або копію. Переважно локальну копію на інший розділ або зовнішній диск.
Якщо не можете — принаймні зробіть снапшот у режимі лише для читання (LVM/ZFS/Btrfs) або tar-архів.

Два правила:

Не виконуйте руйнівні команди в домашньому каталозі користувача, поки не зробили резервну копію.
Не вирішуйте проблему командою «chmod -R 777». Це не виправлення; це генератор інцидентів.

Жарт №1: Якщо ваш план відновлення — «я просто згадаю, що було в Documents», вітаю — ви винайшли послугу втрати даних.

Практичні завдання (з командами, виводом та рішеннями)

Завдання нижче передбачають дистрибутив на базі systemd (Ubuntu, Debian, RHEL-подібні, Fedora тощо) і користувача на імʼя
alice. Налаштуйте імена та шляхи відповідно. Виконуйте від root або через sudo, коли потрібно.

Завдання 1: Підтвердити існування користувача, UID/GID та шлях home

cr0x@server:~$ getent passwd alice
alice:x:1001:1001:Alice Example:/home/alice:/bin/bash

Що це означає: UID=1001, GID=1001, домашній каталог — /home/alice, shell — bash.

Рішення: Якщо шлях home неправильний або вказує на неіснуючий каталог, виправте це перед будь-якими діями
(питання управління користувачами, а не «корупція»).

Завдання 2: Перевірити місце на диску та доступні inode (мовчазні вбивці)

cr0x@server:~$ df -h / /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   39G  420M  99% /
/dev/sda3       200G  120G   70G  64% /home

cr0x@server:~$ df -ih / /home
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2       2.5M  2.5M     0  100% /
/dev/sda3        13M  1.2M   12M    9% /home

Що це означає: Коренева файлова система заповнена на 99% і вичерпано inode на 100%. Це може ламати входи, бо PAM,
системні служби systemd-процесів користувача та компоненти робочого столу потребують створювати файли в /run, /tmp та журнали.

Рішення: Якщо байти або inode близькі до/до 100% на відповідних монтуваннях, звільніть місце перед зачіпанням конфігурації профілю.
«Корупція» може зникнути, щойно ОС зможе дихати.

Завдання 3: Перевірити, чи якась файлова система не в режимі лише для читання через помилки

cr0x@server:~$ mount | egrep ' / | /home '
/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sda3 on /home type ext4 (rw,relatime)

cr0x@server:~$ dmesg | tail -n 8
[12345.678901] EXT4-fs error (device sda2): ext4_find_entry:1455: inode #262210: comm systemd: reading directory lblock 0
[12345.678950] Aborting journal on device sda2-8.
[12345.679010] EXT4-fs (sda2): Remounting filesystem read-only

Що це означає: Ядро перемонтувало / в режимі лише для читання через помилки ext4. Сесії користувачів працюватимуть некоректно та непослідовно.

Рішення: Зупиніть роботу. Заплануйте fsck у режимі обслуговування, перевірте здоровʼя диска і розглядайте це як інцидент зі сховищем.

Завдання 4: Шукайте помилки в журналах (не налагоджуйте в сліпу)

cr0x@server:~$ journalctl -b -p warning --no-pager | tail -n 15
... gdm-password][2100]: pam_unix(gdm-password:session): session opened for user alice(uid=1001) by (uid=0)
... systemd[2140]: Failed to create /home/alice/.cache: Permission denied
... gnome-session[2180]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
... systemd[2140]: Failed at step CHDIR spawning /usr/libexec/gnome-session-binary: Permission denied

Що це означає: Сесія не може створити ~/.cache, і потім GNOME shell падає. Зазвичай це власність/права, заповнений диск або некоректні параметри монтування домашнього каталогу.

Рішення: Перейдіть відразу до перевірки прав домашнього каталогу та параметрів монтування. Скидання налаштувань GNOME не допоможе, якщо неможливо записувати.

Завдання 5: Підтвердити власність та режим домашнього каталогу

cr0x@server:~$ ls -ld /home/alice
drwxr-xr-x 42 root root 4096 Feb  4 10:31 /home/alice

Що це означає: Весь домашній каталог належить root. Користувач не може записувати власні налаштування або кеші.

Рішення: Виправте власність. Але робіть це обережно — спочатку підтвердьте UID (Завдання 1), потім виконуйте chown.

Завдання 6: Безпечно виправити власність (цільове, потім ширше)

cr0x@server:~$ chown alice:alice /home/alice

cr0x@server:~$ find /home/alice -maxdepth 2 -mindepth 1 -user root -print | head
/home/alice/.cache
/home/alice/.config
/home/alice/.local

cr0x@server:~$ chown -R alice:alice /home/alice/.cache /home/alice/.config /home/alice/.local

Що це означає: Ви виправили верхній рівень і ключові ділянки, які багато пишуть, і ідентифікували залишкові файли root поряд з поверхнею.

Рішення: Якщо власність root поширена і виправдана (наприклад, некоректне відновлення з резервної копії), можливо, доведеться зробити повний
chown -R по домашньому каталогу. Якщо в домашньому каталозі є спільні дані або спеціальні монтування, зупиніться і оцініть перед рекурсивними змінами.

Завдання 7: Підтвердити, що користувач може писати в критичні шляхи

cr0x@server:~$ sudo -u alice -H bash -lc 'touch ~/.cache/profile_write_test && echo ok'
ok

Що це означає: Користувач може створювати файли в ~/.cache. Це базова вимога для більшості робочих столів.

Рішення: Якщо це не вдається, у вас ще є проблеми з правами, файловою системою або квотами. Не переходьте далі.

Завдання 8: Перевірити квоти (особливо у корпоративних середовищах)

cr0x@server:~$ quota -u alice
Disk quotas for user alice (uid 1001):
Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/sda3   1024000  1024000 1126400          25000   0       0

Що це означає: Користувач досяг своєї блокової квоти. Операції запису завершуються помилкою «Disk quota exceeded», що часто інтерпретують як «мій профіль пошкоджений».

Рішення: Підвищте квоту або очистіть місце в домашньому каталозі користувача. Скидання dotfiles не вирішить жорстко встановлену квоту.

Завдання 9: Швидко виявити найважчі каталоги (очищення без вандалізму)

cr0x@server:~$ du -xhd1 /home/alice | sort -h
120M	/home/alice/.cache
2.1G	/home/alice/.local
8.4G	/home/alice/Downloads
15G	/home/alice/Documents
26G	/home/alice

Що це означає: Downloads великий; кеш помірний. Documents великий (його слід вважати виробничими даними).

Рішення: Якщо потрібно швидко звільнити місце, почніть з кешів і Downloads, а не з Documents. Також розгляньте системне очищення, якщо корінь зайнятий.

Завдання 10: Зробити безпечну копію Desktop і Documents (збереження метаданих)

cr0x@server:~$ mkdir -p /root/profile-rescue/alice

cr0x@server:~$ rsync -aHAX --info=progress2 /home/alice/Desktop /home/alice/Documents /root/profile-rescue/alice/
sending incremental file list
Documents/
Documents/report.docx
         12,345,678 100%  112.34MB/s    0:00:00 (xfr#1, to-chk=0/3)
Desktop/
Desktop/todo.txt
             1,024 100%    0.01MB/s    0:00:00 (xfr#2, to-chk=0/2)

Що це означає: Ви скопіювали дані збереженням власності, ACL, xattr та жорстких посилань (де підтримується).

Рішення: Якщо rsync видає помилки I/O, зупиніться і дослідіть стан диска. Корупція на цьому етапі — це не «конфігураційний профіль».

Завдання 11: Шукати конфіг, що ламає shell (пастка .bashrc)

cr0x@server:~$ sudo -u alice -H bash --noprofile --norc -lc 'echo shell_ok'
shell_ok

cr0x@server:~$ sudo -u alice -H bash -lc 'echo shell_with_rc_ok'
bash: /home/alice/.bashrc: line 42: syntax error near unexpected token `fi'

Що це означає: Shell працює без стартових файлів, але падає з .bashrc. Це корупція конфігурації.

Рішення: Відсуньте .bashrc убік і відновіть мінімальний відомо робочий варіант. Не видаляйте; помістіть у карантин.

Завдання 12: Помістити підозрілі dotfiles у карантин (хірургічно, зворотньо)

cr0x@server:~$ mkdir -p /home/alice/.profile-quarantine

cr0x@server:~$ mv /home/alice/.bashrc /home/alice/.profile-quarantine/.bashrc.bad

cr0x@server:~$ cp /etc/skel/.bashrc /home/alice/.bashrc

cr0x@server:~$ chown alice:alice /home/alice/.bashrc /home/alice/.profile-quarantine/.bashrc.bad

Що це означає: Ви повернулися до базового шаблону, зберігши старий файл для пізнішого аналізу.

Рішення: Якщо це виправляє термінальні сесії, але GUI все ще падає, проблема в налаштуваннях робочого столу (dconf, розширення GNOME тощо).

Завдання 13: Діагностувати цикл входу GUI, порівнявши з новим користувачем

cr0x@server:~$ useradd -m -s /bin/bash testgui

cr0x@server:~$ passwd -l testgui
passwd: password changed.

Що це означає: Ви створили тестового користувача (у прикладі пароль заблоковано; на практиці можете задати або використовувати SSH-ключі).
Мета — подивитися, чи система може запустити сесію для чистого профілю.

Рішення: Якщо новий користувач входить нормально, а alice — ні, проблема майже напевно в домашньому каталозі/конфігурації Alice, а не в системному графічному стеку.

Завдання 14: Скинути налаштування GNOME (dconf), не торкаючись Documents

cr0x@server:~$ sudo -u alice -H bash -lc 'dconf dump / > /home/alice/.profile-quarantine/dconf-backup.ini'

cr0x@server:~$ sudo -u alice -H bash -lc 'rm -f ~/.config/dconf/user'

cr0x@server:~$ sudo -u alice -H bash -lc 'echo "dconf reset staged"'
dconf reset staged

Що це означає: Ви зробили бекап бази dconf і видалили її, щоб GNOME створив значення за замовчуванням.

Рішення: Якщо GNOME тепер стартує, стара база dconf (або налаштування розширення) була токсичною. Повертаючи налаштування поступово, не робіть сліпого відновлення.

Завдання 15: Виправити зламані XDG user dirs (шляхи Desktop/Documents)

cr0x@server:~$ sudo -u alice -H bash -lc 'cat ~/.config/user-dirs.dirs'
XDG_DESKTOP_DIR="$HOME/Desktoop"
XDG_DOCUMENTS_DIR="$HOME/Documants"

cr0x@server:~$ sudo -u alice -H bash -lc 'xdg-user-dirs-update && cat ~/.config/user-dirs.dirs'
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Music"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEOS_DIR="$HOME/Videos"

Що це означає: Оточення робочого столу вказувало на неправильно написані каталоги. Це може проявлятися як «робочий стіл порожній», хоча файли існують.

Рішення: Якщо user-dirs неправильні, виправте їх і створіть каталоги, якщо вони відсутні. Не переміщуйте дані, поки шляхи не виправлено.

Завдання 16: Перевірити і відновити контексти SELinux (якщо застосовується)

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ ls -Zd /home/alice
unconfined_u:object_r:default_t:s0 /home/alice

cr0x@server:~$ restorecon -Rv /home/alice | tail -n 5
restorecon reset /home/alice context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:user_home_dir_t:s0
restorecon reset /home/alice/.ssh context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:ssh_home_t:s0

Що це означає: Контексти були неправильні. SELinux може блокувати читання/запис у спосіб, який виглядає як випадкові збої програм.

Рішення: Якщо SELinux у режимі Enforcing і контексти неправильні, виправте їх перед зміною прав. SELinux не вражений chmod.

Завдання 17: Перевірити здоровʼя файлової системи (приклад ext4)

cr0x@server:~$ smartctl -H /dev/sda
SMART overall-health self-assessment test result: PASSED

cr0x@server:~$ touch /forcefsck && echo "scheduled"
scheduled

Що це означає: SMART каже, що диск у порядку (не гарантія), і ви запланували fsck при наступному завантаженні.

Рішення: Якщо раніше були помилки I/O, все одно плануйте технічне обслуговування. Пошкодження профілю, спричинене ненадійним сховищем, повторюватиметься, поки ви не вирішите корінну причину.

Стратегія чистої перебудови: новий користувач, міграція даних, поступове відновлення налаштувань

Іноді найшвидший шлях — не ремонтувати. Це замінити профіль: створити нового користувача, скопіювати справжні дані
(Desktop/Documents тощо), а потім вибірково повертати налаштування. Це той самий підхід, який використовують SRE: cattle-not-pets,
застосований до домашнього каталогу людини.

Чому це працює: профіль робочого столу Linux накопичує стан. Розширення, кеші, теми, старі сокети,
помічники автентифікації, «слізь» від electron-додатків, биті симлінки і десятирічний dotfile, про який ви забули.
Якщо намагатися виправити все на місці, ви будете ганятися за привидами днями. Контрольована міграція дозволяє зупинити кровотечу.

Як зробити це, не втративши Desktop/Documents

Створіть нового користувача (наприклад, alice2) з чистим домашнім каталогом.
Спочатку копіюйте тільки «дані»: Desktop, Documents, Pictures тощо.
Перевірте права і логін під новим користувачем.
Лише потім вибірково переносіть потрібні каталоги конфігурацій (SSH-ключі, можливо профіль браузера), по одному.
Зберігайте старий домашній каталог недоторканим, поки не пройдете тиждень з новим профілем.

cr0x@server:~$ useradd -m -s /bin/bash alice2

cr0x@server:~$ rsync -aHAX --info=progress2 /home/alice/Documents /home/alice/Desktop /home/alice/Pictures /home/alice2/
sending incremental file list
Documents/
Desktop/
Pictures/

cr0x@server:~$ chown -R alice2:alice2 /home/alice2/Documents /home/alice2/Desktop /home/alice2/Pictures

Точка рішення: Якщо новий користувач працює, ви довели, що системний стек в порядку, а старий профіль був проблемою. Тепер можна
вирішити, чи залишити нового користувача назавжди або після очищення повернутися до оригінального імені.

Що не варто переносити першим

~/.cache — це кеш. Нехай він відновиться.
~/.config цілком — тут живуть зламані налаштування робочого столу.
~/.local/share цілком — частина цінна (шрифти, дані додатків), частина — сміття. Обирайте селективно.
Невідомі dotfiles з 2014 року — вони повернуть вас у 2014, і не в хорошому сенсі.

Жарт №2: Переносити ~/.cache, щоб «заощадити час», — це як пакувати кухонне сміття, щоб «зберегти запах».

Особливості GNOME/KDE: dconf, кеші та чому зникає робочий стіл

Більшість повідомлень «мій робочий стіл зник» насправді означають, що сесія робочого столу не стартувала або стартувала,
але не прочитала потрібні каталоги. GNOME і KDE залежать від:

можливості запису в домашні каталоги для кешів і runtime-стану;
демонів сесії, керованих systemd user units;
сховищ налаштувань (GNOME: dconf, KDE: переважно текстові конфіги під ~/.config);
мапування XDG каталогів, яке каже додаткам, де Desktop і Documents.

GNOME: dconf — єдина точка «чому це відбувається»

Налаштування GNOME зберігаються в бінарній базі dconf за адресою ~/.config/dconf/user. Якщо вона пошкоджена
або містить налаштування, що падають GNOME Shell (часто через розширення), ваш вхід може зациклитися або потрапити в зламану сесію.

Правильний крок той, що ви бачили раніше: зробити бекап, видалити і дати GNOME відтворити значення за замовчуванням. Потім обережно
ставитися до розширень. У корпоративних образах розширення часто «стандартизовані». Переклад: хтось одного разу полюбив налаштування, і тепер це політика.

KDE Plasma: текстові конфіги полегшують ізоляцію, але й легше зіпсувати

KDE зберігає багато в ~/.config як звичайні текстові файли (схожі на INI). Це полегшує пошук поганої опції і її виправлення.
Але це також робить простим для скриптів, напівготових менеджерів dotfile та інструментів «закріплення» записувати некоректні конфіги.

Якщо Plasma не стартує, типовими винуватцями є зламані файли на кшталт plasmashellrc, автозапуски або права, що заважають KDE
створювати сокети під ~/.cache або ~/.config.

Режими відмов файлової системи та сховища (погляд SRE)

Профіль користувача не існує сам по собі. Він лежить на сховищі. Сховище «бреше» цікавими способами.

Повний диск — це не просто «немає місця»

Повний диск може означати:

Вичерпання блоків: використано байти, класична проблема df -h.
Вичерпання inode: занадто багато дрібних файлів, класичний сюрприз df -i.
Вичерпання квот: користувач досяг обмеження на спільному файловому сховищі.

Усі три випадки можуть ламати входи, браузери та робочі столи. Вони також можуть спричинити часткові невдалі записи конфігів, що створює
ілюзію «пошкодження» пізніше.

Перемонт у режимі лише для читання — це ядро, що постукує по плечу

Коли ext4 виявляє помилки метаданих, він може перемонтувати в режимі read-only, щоби не погіршувати ситуацію. Користувачі тоді кажуть:
«Мій робочий стіл не зберігає налаштування» або «Я не можу створювати файли». Це не проблема профілю — це файлова система, що себе захищає.

Мережеві home (NFS/SMB) додають затримок та проблем узгодженості

У корпоративних середовищах домашні каталоги часто знаходяться на NFS. Якщо сервер сповільнюється або мережа ламається, робочий стіл
може зависнути під час входу, чекаючи dotfiles, keyring або D-Bus служби. Ви бачитимете таймаути та помилки «stale file handle».

Одна операційна цитата, яку варто приклеїти до монітора

Надія — не стратегія. (парафраз ідеї, поширеної в інженерії/операціях)

В термінах відновлення профілю: не «надійтеся», що робочий стіл повернеться після випадкових видалень. Вимірюйте, копіюйте, ізолюйте і перевіряйте.

Три корпоративні міні-історії з полів

Міні-історія 1: Інцидент через неправильне припущення

Компанія розгорнула політику безпеки, яка звужувала права на домашні каталоги користувачів. Звучить розумно: «зробити домашні каталоги незчитуваними для всіх».
Реалізація, однак, припускала, що кожен home живе локально і що власність скрізь узгоджена.

Насправді половина паркета використовувала мережеві домашні каталоги. Скрипт політики виконався рано під час завантаження, до того як NFS змонтувався.
Він створив /home/alice локально під root (бо монтування ще не було), потім застосував нові «безпечні» права. За кілька хвилин NFS змонтувався на /home,
але для деяких користувачів локальні каталоги вже були неправильними, залежно від часу.

Симптоми були хаотичні: цикли входу, відсутні іконки Desktop і програми, що відмовлялися запускатися. Команда спочатку звинуватила оновлення GNOME, бо це збіглося у часі.
Розумна історія, але неправильний винуватець.

Виправлення було нудним: порядок монтування, ідемпотентні перевірки (змінюйте директорію лише якщо вона на очікуваному файловому сховищі) і крок перевірки,
що порівнював вихід stat з очікуваним UID/GID. Також припинили створювати каталоги, коли монтування відсутнє.
«Припустити» стало забороненим словом на час у code-review.

Міні-історія 2: Оптимізація, що дала зворотний ефект

Інша організація хотіла пришвидшити входи на спільних робочих станціях. Хтось помітив, що ~/.cache великий, і його видалення ніби пришвидшує запуск деяких додатків.
Тому створили щотижневу задачу: чистити кеші для всіх користувачів.

Робота виконувалася від root, звісно.

Декілька тижнів все було добре. Потім почалися звернення: «Мій робочий стіл забуває налаштування», «Keyring просить пароль при кожному вході»,
«Профілі браузера постійно «відновлюються»», «Іконки на робочому столі перемішані». Декілька сесій навіть не стартували.

Корінь проблеми не в очищенні кешів як такій. Проблема була в тому, як це робилося. Задача видаляла і створювала деякі каталоги заново,
залишаючи їх власністю root. При наступному вході оточення робочого столу намагалося писати в ~/.cache і не могло.
Деякі програми вважали це фатальним, інші переходили на дивні налаштування.

Відкат був негайним: зупинити задачу, відновити правильну власність, і якщо очищення кешу потрібне — виконувати його від імені користувача при логіні
або використовувати tmpfiles.d політики, що не топчуть власність. Оптимізація додала мілісекунди і забрала дні продуктивності.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Команда вела невелике VDI-середовище для підрядників. Домашні каталоги жили на спільному масиві. Люди входили, редагували документи й йшли. Передбачуване навантаження — поки не сталося інакше.

Одного ранку частина користувачів повідомила, що їхні Documents зникли, а робочий стіл порожній. Паніка зростала, бо «зниклі Documents» — це спосіб залучити керівництво.
Інженер на виклику не почав відновлення з бекапа.

Замість цього він пройшов чеклист: підтвердити монтування, перевірити XDG dirs, перевірити права і порівняти з відомо робочим користувачем.

Виявилось, що сховище в порядку. Домашні каталоги змонтовано. Дані існували. Проблема була в шаблоні, що розгорнули: пошкоджений ~/.config/user-dirs.dirs для частини користувачів.
Desktop і Documents вказували на неправильно написані шляхи. Дані не зникли; зникли вказівники.

Нудна практика — мати стандартну діагностику «здоровʼя логіну» і завжди перевіряти реальні шляхи — запобігла непотрібному відновленню,
уникнула зайвого навантаження на масив і зберегла інцидент малим. Однорядкова правка (xdg-user-dirs-update) перемогла багатогодинне відновлення, яке породило б нові проблеми.

Цікаві факти та історичний контекст

Факт 1: Концепція «домашнього каталогу» користувача походить з раннього Unix, де користувацький стан зберігався під /usr до широкого впровадження /home.
Факт 2: Dotfiles стали звичаєм, бо приховані файли були простим способом тримати конфігурацію поза випадковими переліками каталогів.
Факт 3: dconf у GNOME замінив старіший GConf, щоб покращити продуктивність і централізувати доступ до налаштувань.
Факт 4: Специфікація XDG була введена, щоб зменшити хаос від розкидання налаштувань/стану по домашньому каталогу.
Факт 5: Вичерпання inode — давня проблема, що стала частішою з ростом кешів пакетів, node_modules та профілів браузерів, що містять тисячі дрібних файлів.
Факт 6: Проблеми «цикл входу» часто повʼязані з PAM та налаштуванням сесії, а не з перевіркою пароля — автентифікація проходить, а створення сесії не вдається.
Факт 7: Контексти SELinux важливі, бо політика безпеки може забороняти доступ навіть якщо Unix-права виглядають коректно.
Факт 8: Мережеві домашні каталоги стали популярні в підприємствах, бо централізовані бекапи і roaming-профілі спрощують управління, але додають ризики затримок і доступності.
Факт 9: /etc/skel існує саме для того, щоб заповнювати нові домашні каталоги базовими dotfiles — використовуйте його як «відомо робочий» шаблон.

Поширені помилки: симптом → корінна причина → виправлення

Це помилки, які я бачу часто, бо їх легко спровокувати і важко розпізнати.

Цикл входу (пароль прийнято, повертаєтеся до екрану входу)

Симптом: Облікові дані приймаються, екран блимає, ви повертаєтесь на GDM/SDDM.
Корінна причина: Домашній каталог недоступний для запису (права, квота, перемонт у read-only) або сесія робочого столу падає через конфіг.
Виправлення: Перевірте journalctl на «Permission denied» і «Disk quota exceeded». Виправте можливість запису спочатку; потім скиньте dconf або помістіть у карантин каталоги конфігурацій робочого столу.

Папка Desktop виглядає порожньою, але файли є в home

Симптом: Робочий стіл показує нічого; термінал показує файли в ~/Desktop або в іншому місці.
Корінна причина: Некоректне мапування XDG у ~/.config/user-dirs.dirs або локалізована невідповідність каталогів.
Виправлення: Запустіть xdg-user-dirs-update, перевірте шляхи і переконайтеся, що каталоги існують з правильною власністю.

Програми відмовляються запускатися; помилки про cache/config

Симптом: Браузер/electron-додатки падають; помилки про ~/.cache або ~/.config.
Корінна причина: Каталоги належать root через невдалий скрипт очищення або відновлення.
Виправлення: chown постраждалих каталогів назад користувачу; перевірте створення файлу від імені користувача.

Термінал працює, але інтерактивний shell зламаний

Симптом: Неінтерактивні команди виконуються; інтерактивні сесії видають помилки.
Корінна причина: Зламані .bashrc, .profile або скрипт менеджера плагінів, що припускає наявність бінарів.
Виправлення: Почніть з bash --noprofile --norc. Помістіть dotfiles у карантин і відновіть з /etc/skel.

Виглядає все правильно, але доступ заборонено на SELinux-системах

Симптом: Права виглядають коректно; все одно «Permission denied». Аудит-журнали показують відмови.
Корінна причина: Неправильний контекст SELinux у домашньому каталозі після відновлення або ручного копіювання.
Виправлення: restorecon -Rv /home/username і повторна перевірка.

«Пошкодження профілю» повертається після того, як ви його виправили

Симптом: Той самий користувач знову ламається через кілька тижнів.
Корінна причина: Проблеми з файловою системою, ненадійний диск або повторювана автоматизація, що топче власність.
Виправлення: Перегляньте dmesg, SMART, результати fsck і автоматизацію в парку. Виправте систему, яка ламає профіль.

Контрольні списки / покрокові плани

Чеклист A: Мінімальний ризик відновлення (залишити те саме імʼя користувача)

Увійдіть через TTY або SSH як адміністратор/root (уникайте зламаної GUI-сесії поки що).
Перевірте місце на диску і inode на / та /home.
Перевірте перемонт у режимі read-only і помилки I/O.
Зробіть бекап ~/Desktop і ~/Documents (rsync з метаданими).
Перевірте власність та права домашнього каталогу (ls -ld і тест запису від імені користувача).
Помістіть у карантин лише ймовірних винуватців:
- ~/.config/dconf/user (GNOME)
- shell-dotfiles (.bashrc, .profile)
- кеші робочого столу (~/.cache), якщо потрібно
Виправте мапування XDG user dirs, якщо Desktop/Documents «зникли».
Повторіть вхід. Якщо працює, поступово повертайте карантинні конфіги по одному.

Чеклист B: Чиста перебудова (новий користувач, міграція даних)

Створіть нового користувача з чистим домашнім каталогом.
Копіюйте тільки дані (Desktop/Documents/Pictures тощо).
Підтвердьте права, вхід і поведінку додатків.
Копіюйте лише конкретні конфіги, які потрібні:
- ~/.ssh (акуратно з правами)
- специфічні каталоги додатків під ~/.config (не весь каталог)
- вибірково: профілі браузерів, дані менеджера паролів (тільки якщо знаєте, що робите)
Зберігайте оригінальний домашній каталог як архів, поки не будете впевнені.

Чеклист C: Ремонтувати сховище спочатку (коли система — проблема)

Якщо файлова система в режимі read-only: припиніть відновлення профілю; заплануйте технічне обслуговування.
Запустіть SMART-перевірки і перегляньте журнали ядра на помилки I/O.
Запустіть fsck (ext4) або відповідні інструменти для ремонту (XFS вимагає іншого підходу).
Тільки після стабілізації сховища: переходьте до відновлення або міграції профілю.

Питання та відповіді

1) Що вважається «Desktop і Documents» у Linux?

Зазвичай ~/Desktop і ~/Documents, але оточення робочого столу може використовувати XDG-мапінг з
~/.config/user-dirs.dirs. Завжди перевіряйте цей файл перед переміщенням чогось.

2) Якщо я видалю `~/.config`, чи втратяться мої файли?

Ви прямо не втратите Documents, але можете втратити налаштування додатків, збережені сесії і інколи дані додатків, що зберігаються під
~/.config або ~/.local/share. Не видаляйте все підряд. Поміщайте у карантин і відновлюйте вибірково.

3) Чому повний кореневий розділ ламає вхід користувача?

Тому що системні служби потребують писати стан, журнали та runtime-файли. Навіть якщо в домашньому каталозі є місце, повний /
може перешкодити налаштуванню сесії, активації D-Bus або роботи Credential Helper.

4) Як зрозуміти, що це не проблема драйвера графіки?

Створіть нового користувача і спробуйте увійти. Якщо новий користувач працює, ваш графічний стек майже напевно в порядку. Якщо ніхто не може увійти,
проблема на рівні системи (графіка, display manager або сховище).

5) Чи можу я виправити це скиданням прав через `chmod -R`?

Можна так само «вирішити» шум двигуна, ввімкнувши гучніше радіо. Не робіть цього. Скидання прав без розуміння власності, ACL і SELinux
створює проблеми безпеки і може не вирішити проблему сесії.

6) Який найбезпечніший спосіб «скинути» профіль?

Створіть нового користувача і копіюйте лише дані-папки спочатку. Це відновлювано, тестовано і уникає гонитви за конфігураційними привидами.

7) Мої файли є, але я не можу їх відкрити. Що робити?

Перевірте власність і права файлів та батьківських каталогів, і підтвердьте, що UID відповідає очікуваному значенню облікового запису.
Якщо файли належать старому UID (після відновлення), зробіть chown з урахуванням числового відображення UID.

8) Як впоратися з пошкодженим профілем браузера без втрати закладок?

Спочатку зробіть бекап каталогу профілю браузера. Потім експортуйте закладки, якщо браузер може стартувати. Якщо ні — мігруйте лише файли бази закладок
у свіжий профіль (це специфічно для браузера). Уникайте копіювання всього зламаного профілю як «виправлення».

9) Чому власність `~/.cache` така важлива?

Тому що сучасні робочі столи і додатки трактують кеш як місце для запису тимчасових даних. Якщо вони не можуть писати туди, вони поводяться непередбачувано:
аварії, відсутній UI-стан і цикли старту.

10) Коли слід зупинитися і відновити з бекапу?

Якщо бачите помилки I/O під час читання, повідомлення про корупцію файлової системи або повторні помилки при копіюванні даних користувача — припиніть налагодження профілю.
Стабілізуйте сховище і відновіть з відомого доброго бекапу або снапшоту.

Висновок: подальші кроки, які тримають вас подалі від проблем

Відновлення пошкодженого профілю користувача — це здебільшого про опір спокусі безладно щось видаляти. Почніть з фундаменту: місце на диску, inode, перемонти read-only,
власність і квоти. Зробіть бекап Desktop і Documents перед «чисткою» чого-небудь. Далі поміщайте конфігураційні файли у карантин як професіонал, а не гравець у покер.

Практичні наступні кроки:

Пройдіть швидкий план діагностики і запишіть спостереження (місце, права, read-only, журнали).
Зробіть перевірену копію Desktop і Documents через rsync.
Виправте проблеми з можливістю запису перш за все (власність, квоти, контексти SELinux).
Якщо конфіг — винуватець, скиньте dconf (GNOME) або помістіть у карантин конкретні файли KDE — по одній зміні за раз.
Якщо витрачаєте забагато часу, зробіть чисту перебудову: новий користувач, міграція даних і лише навмисне повернення налаштувань.