«Доступ заборонено» до власних файлів після переінсталяції: виправлення власності

Що насправді відбувається: імена брешуть, числа — ні

Власність файлів у Linux зберігається як числові ідентифікатори: UID (ідентифікатор користувача) і GID (ідентифікатор групи). Рядок «alice» — лише пошук у /etc/passwd (або LDAP/SSSD). Ваш файл каже «власник — UID 1001». Система перекладає 1001 у імʼя, якщо може. Після перевстановлення «alice» може тепер бути UID 1000, а 1001 може належати нікому — або, ще гірше, іншому обліковому запису.

Отже, ви заходите під «alice», але ваші файли належать «UID 1001», а ваша нова «alice» — UID 1000. Ядро перевіряє числа, а не почуття. Перевірка не проходить. Ви отримуєте «Permission denied».

Це основна історія. Але в продуктивних систем є сюжетні повороти:

• ACL можуть переважати класичні rwx біти. Ви можете «володіти» файлом і все одно отримувати відмову.
• Параметри монтування файлової системи можуть маскувати або вигадувати власність (поширено для FAT/NTFS/CIFS).
• Мережеві файлові системи можуть переписувати ідентичність (NFS idmapping, root squash, Kerberos).
• Шари шифрування можуть змінювати, хто може відкрити файл (eCryptfs, fscrypt; LUKS зазвичай працює добре).
• SELinux/AppArmor може сказати «ні», навіть коли права явно дозволяють.

І так, ви можете «виправити» це chmod 777. Ви також можете відремонтувати автомобіль, знявши гальма. Обидва підходи швидкі та пізнавальні.

Одна цитата, яку варто тримати в голові, коли хочеться знищити права: «Надія — не стратегія.» — Gene Kranz.

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

Це найшвидший шлях до виявлення вузького місця. Робіть ці кроки в порядку. Кожен крок підкаже, чи маєте ви справу з невідповідністю UID/GID, ACL, особливостями монтування або шарами безпеки.

1) Підтвердьте, що помилка стосується прав/власності, а не диска чи пошкодження

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

2) Перевірте, хто ви є (числа) і хто власник файлу (числа)

• Якщо ваш UID відрізняється від UID файлу: у вас класична невідповідність після перевстановлення.
• Якщо числа співпадають, але все одно відмовляють: дивіться ACL, незмінні атрибути, SELinux/AppArmor або опції монтування.

3) Перевірте тип монтування та опції

• FAT/NTFS/CIFS часто «фейкують» власність. Ваш chown може нічого не робити.
• NFS може відображати ідентичності; власність «nobody» — великий натяк.
• Монтування лише для читання трапляється після відновлення журналу, аварійного вимкнення або при явному ro.

4) Перевірте ACL та атрибути

• Відмови через ACL часто зустрічаються на корпоративних десктопах і в командних каталога
• Незмінний біт (chattr +i) рідкісний, але незабутній.

5) Лише тоді застосовуйте виправлення

• Переважайте цілеспрямований chown над рекурсивним «гасінням пожежі».
• Переважайте числові зміни власності при міграції між системами.
• Не «виправляйте» монтування, яке не підтримує власність, намагаючись примусово виконати chown; ви витратите час.

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

Нижче наведені реальні завдання, які можна виконати. Кожне містить: команду, що означає вихід, і рішення, яке слід прийняти. Запускайте їх з shell із відповідними правами. Якщо сумніваєтеся, починайте в режимі лише читання і підвищуйте привілеї обережно.

Завдання 1: Перевірте свою поточну числову ідентичність

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo),118(lpadmin)

Значення: Ваш обліковий запис має UID 1000, первинний GID 1000. Саме ці числа використовує ядро для перевірок дозволів.

Рішення: Запишіть ці числа; ви порівнюватимете їх з власністю файлів.

Завдання 2: Перевірте проблемний файл з числовими власниками

cr0x@server:~$ ls -ln /mnt/oldhome/cr0x/Documents/report.txt
-rw------- 1 1001 1001 8421 Jan 12 09:14 /mnt/oldhome/cr0x/Documents/report.txt

Значення: Файл належить UID 1001 і GID 1001. Ваш поточний користувач — 1000. Ця невідповідність — явний доказ.

Рішення: Плануйте зміну власності з 1001:1001 на 1000:1000 (або на правильний цільовий користувач/групу).

Завдання 3: Підтвердіть, кому відповідає UID 1001 у цій системі

cr0x@server:~$ getent passwd 1001

Значення: Відсутній вивід означає, що UID 1001 не призначено жодному користувачу в цій системі.

Рішення: Безпечно перепризначити власність з 1001, якщо 1001 відповідав вашому старому обліковому запису на попередній інсталяції.

Завдання 4: Перевірте тип файлової системи та параметри монтування

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/oldhome
/dev/sdb2 ext4 rw,relatime

Значення: ext4 підтримує Unix-власність і дозволи. chown працюватиме як очікується.

Рішення: Продовжуйте з виправленням власності на рівні файлової системи.

Завдання 5: Виявити монтування лише для читання (супутній тихий вбивця дозволів)

cr0x@server:~$ mount | grep ' /mnt/oldhome '
/dev/sdb2 on /mnt/oldhome type ext4 (rw,relatime)

Значення: Воно змонтоване для запису (rw). Якби ви побачили ro, записи б не відбувалися незалежно від власності.

Рішення: Якщо ro, перемонтуйте як rw (після перевірки логів) замість гонитви за правами.

Завдання 6: Спробуйте недеструктивний тест запису

cr0x@server:~$ touch /mnt/oldhome/cr0x/.permtest
touch: cannot touch '/mnt/oldhome/cr0x/.permtest': Permission denied

Значення: Каталог забороняє запис для вашого UID. Це відповідає невідповідності власності.

Рішення: Виправте власність дерева директорій (або принаймні потрібних шляхів для запису).

Завдання 7: Перевірте власність і режим директорії (директорії — це ворота)

cr0x@server:~$ ls -ldn /mnt/oldhome/cr0x
drwx------ 72 1001 1001 4096 Feb  1 18:22 /mnt/oldhome/cr0x

Значення: Директорія має 0700 і належить 1001. Лише UID 1001 може читати/писати/заходити в неї.

Рішення: Власність потрібно змінити, інакше вміст не матиме значення.

Завдання 8: Попередній перегляд того, що ви збираєтеся змінити (пошук за числовим UID)

cr0x@server:~$ sudo find /mnt/oldhome/cr0x -xdev -uid 1001 -maxdepth 2 -printf '%u:%g %m %p\n' | head
1001:1001 700 /mnt/oldhome/cr0x
1001:1001 700 /mnt/oldhome/cr0x/.ssh
1001:1001 600 /mnt/oldhome/cr0x/.ssh/authorized_keys
1001:1001 644 /mnt/oldhome/cr0x/.bashrc
1001:1001 700 /mnt/oldhome/cr0x/Documents

Значення: Ви бачите картину змін. Параметр -xdev утримує пошук в цій файловій системі (важливо, якщо ~/ містить монтування).

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

Завдання 9: Безпечно виправте власність (цілеспрямовано, рекурсивно, залишаючись в одній файловій системі)

cr0x@server:~$ sudo chown -R --from=1001:1001 1000:1000 /mnt/oldhome/cr0x

Значення: Це змінює власність тільки якщо поточний власник/група відповідають 1001:1001. Це запобігає «ой, а я змінив чужі файли».

Рішення: Використовуйте --from при міграції власності між перевстановленнями. Це пасок безпеки, який реально працює.

Завдання 10: Повторно перевірте доступ на запис

cr0x@server:~$ touch /mnt/oldhome/cr0x/.permtest
cr0x@server:~$ ls -l /mnt/oldhome/cr0x/.permtest
-rw-r--r-- 1 cr0x cr0x 0 Feb  4 10:11 /mnt/oldhome/cr0x/.permtest

Значення: Тепер ви можете записувати; власність і дозволи співпадають з вашою поточною ідентичністю.

Рішення: Видаліть тестовий файл і перевірте чутливі теки, наприклад .ssh.

Завдання 11: Перевірте й укріпіть дозволи .ssh (типова післяфіксова поломка)

cr0x@server:~$ chmod 700 /mnt/oldhome/cr0x/.ssh
cr0x@server:~$ chmod 600 /mnt/oldhome/cr0x/.ssh/authorized_keys
cr0x@server:~$ ls -ld /mnt/oldhome/cr0x/.ssh
drwx------ 2 cr0x cr0x 4096 Feb  4 10:08 /mnt/oldhome/cr0x/.ssh

Значення: SSH вимогливий; очікує жорсткі режими. Виправлення власності іноді залишає групові біти для запису, і SSH відмовиться використовувати ключі.

Рішення: Нормалізуйте .ssh зараз, щоб не витрачати час на налагодження «Permission denied (publickey)» пізніше.

Завдання 12: Перевірте ACL, які все ще можуть забороняти доступ

cr0x@server:~$ getfacl -p /mnt/oldhome/cr0x/Documents | sed -n '1,20p'
# file: /mnt/oldhome/cr0x/Documents
# owner: cr0x
# group: cr0x
user::rwx
group::---
other::---
default:user::rwx
default:group::---
default:other::---

Значення: Тут немає неочікуваних заборон через ACL; це фактично семантика 0700 з дефолтними ACL для нових файлів.

Рішення: Якщо ви бачите записи типу user:cr0x:--- або маску, яка обмежує, виправляйте ACL, а не бездумно застосовуйте chmod.

Завдання 13: Якщо власність «не змінюється», переконайтесь, що це не NTFS/FAT або CIFS

cr0x@server:~$ findmnt -no FSTYPE,OPTIONS /mnt/share
cifs rw,relatime,vers=3.1.1,cache=strict,username=cr0x,uid=1000,gid=1000,file_mode=0644,dir_mode=0755

Значення: CIFS показує власність через опції монтування. chown зазвичай не збережеться, бо сервер керує правами (або клієнт їх підробляє).

Рішення: Виправляйте власність/права на боці сервера (Samba/Windows ACL) або підлаштуйте опції монтування (uid=, gid=, file_mode=, dir_mode=).

Завдання 14: Якщо на NFS видно «nobody», перевірте idmapping

cr0x@server:~$ ls -ln /mnt/nfs/home/cr0x | head
drwx------  5 65534 65534 4096 Feb  3 14:20 .
drwxr-xr-x 12 65534 65534 4096 Feb  3 14:20 ..

Значення: UID/GID 65534 зазвичай означає «nobody/nogroup». Клієнт і сервер не погоджують відображення ідентичностей.

Рішення: Виправте NFS idmapping (однакові UID/GID на всіх хостах, або правильна конфігурація idmapd, або використовуйте NFSv4 з узгодженими ідентичностями).

Завдання 15: Перевірте незмінний атрибут (чому chmod/chown «не працює»)

cr0x@server:~$ lsattr -d /mnt/oldhome/cr0x/Documents
-------------e------- /mnt/oldhome/cr0x/Documents

Значення: Немає прапора i, отже це не незмінний файл. Якби ви бачили ----i--------, зміни були б заблоковані навіть для root.

Рішення: Якщо є незмінний біт, зніміть його з допомогою chattr -i (обережно і лише там, де це обґрунтовано).

Завдання 16: Перевірте відмови SELinux (коли все виглядає правильно, але все одно не працює)

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 3
type=AVC msg=audit(1707041254.332:812): avc:  denied  { write } for  pid=2419 comm="vim" name="report.txt" dev="sdb2" ino=931281 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0

Значення: SELinux відмовляє у записі на підставі міток (tcontext), а не Unix-прав.

Рішення: Відновіть правильні контексти (часто за допомогою restorecon) замість послаблення Unix-прав.

Виправлення власності, які не підпалять систему

Правильне виправлення залежить від того, де зберігаються файли і як вони створювалися. Але золоте правило одне: виправляйте ідентичність, не заклеюйте проблему.

Найкращий сценарій: локальна Linux файловa система (ext4/xfs/btrfs)

Якщо файли на стандартній Linux-файловій системі, і вашому користувачу присвоїли новий UID після перевстановлення, у вас є два чистих варіанти:

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

Я віддаю перевагу опції 2 для персональних десктопів та ноутбуків. Опцію 1 — для серверів зі спільним сховищем, NFS чи будь-чого, що потребує стабільної ідентичності між вузлами.

Виправляти файли (chown) vs. змінювати обліковий запис (usermod)

Варіант A: Змінити власність старого домашнього каталогу

Ви вже бачили безпечний шаблон: chown -R --from=OLDUID:OLDGID NEWUID:NEWGID. Це нудно і правильно. І це комплімент.

Будьте хірургічні:

• Використовуйте -xdev з find, щоб не переходити в змонтовані піддерева.
• Зробіть попередній перегляд (find ... -uid OLDUID) перед змінами.
• Не запускайте рекурсивний chown на /. Там живе божевілля.

Варіант B: Підлаштувати нового користувача під старий UID/GID

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

cr0x@server:~$ id cr0x
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)

cr0x@server:~$ sudo usermod -u 1001 cr0x
cr0x@server:~$ sudo groupmod -g 1001 cr0x

Значення: Ви змінили числову ідентичність облікового запису. Існуючі файли, що належали 1000, можуть тепер бути «сиротами» і потребуватимуть додаткового chown з 1000 на 1001.

Рішення: Робіть це лише якщо 1001 вільний і ви розумієте радіус ураження (сервіси, cron, контейнери, системні користувачі). Це стабільно, але не легковажно.

Операційна порада: Якщо це багатокористувацька система, координуйте розподіл UID/GID. На флоті використовуйте централізовану ідентичність (LDAP/FreeIPA/AD) або сувору політику UID. Ад-хок локальні користувачі — це шлях до «це ж працювало на старому сервері» як стилю життя.

Коли chmod — не те, що треба (здебільшого тут)

chmod змінює біти режиму. Він не змінює власність. Якщо файли належать UID 1001, а ви UID 1000, chmod не зробить вас власником. Він може надати доступ групі/іншим, що іноді прийнятно для спільних даних, але зазвичай це регресія безпеки для особистих домашніх каталогів.

Використовуйте chmod для того, для чого він призначений:

• Виправлення режимів директорій (відсутній біг виконання на директоріях).
• Нормалізація режимів .ssh.
• Налаштування setgid на командних каталогах для передбачуваної групової власності.

Використовуйте chown, щоб виправити «хто ви є».

Особливі випадки: ACL, NFS, Samba, FAT/NTFS, ZFS, контейнери

POSIX ACL: невидимий шар, що може переважати очікування

ACL додають записи для окремих користувачів і груп поза класичною триадою власник/група/інші. Вони також вводять маску, яка може непомітно зменшувати ефективні дозволи.

Типовий біль після перевстановлення:

• Ви правильно зробили chown всього. І все одно не можете писати. ACL забороняє або маска обмежує.
• Нові файли в директорії успадковують дефолтні ACL, про які ви забули.

Діагностика проста: getfacl. Виправлення залежить від наміру:

• Якщо ACL — випадковий вантаж: видаліть їх setfacl -b (і, можливо, очистіть дефолти setfacl -k).
• Якщо ACL — задумано (спільний каталог): відкоригуйте записи і маску належним чином.

NFS: ідентичність має збігатися з обох сторін

NFS не робить «cr0x» тим самим на всіх хостах. Класичний NFSv3 — переважно числовий. NFSv4 може використовувати імена з idmapping, але неправильні налаштування часті, особливо після перевстановлення, коли /etc/idmapd.conf має інші значення за замовчуванням.

Підказки, що ви в NFS-середовищі:

• Файли показують UID/GID 65534 («nobody»).
• Root не може виконати chown через обмеження на сервері.
• Дозволи залежать від того, на якому хості ви дивитесь.

Стратегія виправлення:

• Переважайте узгоджений розподіл UID/GID між хостами (централізована ідентичність або сувора локальна політика).
• Перевірте опції експорту NFS і чи діє root squashing.
• Не «виправляйте» chmod 777 на спільних експортax. Це лише поширить проблему.

Samba/CIFS: ваш Linux UID тут не керує

У SMB-доступах керують переважно серверні ACL та автентифікація. Опції монтування клієнтом можуть відобразити власність для відображення й локальних перевірок, але вони не перепишуть серверну думку про те, хто може що робити.

Наслідок: якщо ви не можете отримати доступ до файлів на Samba-шарі після перевстановлення, не починайте з chown. Почніть з:

• Облікових даних і членства в домені
• Наслідування серверних ACL
• Опцій монтування (uid, gid, nounix, mfsymlinks тощо)

FAT/NTFS: права — здебільшого маскарад

FAT не має Unix-власності. NTFS має Windows ACL; драйвери Linux можуть їх відобразити, але багато конфігурацій використовують спрощену модель прав.

Симптоми:

• chown повертає «Operation not permitted» або виглядає як успіх, але не зберігається.
• Все показує власником UID/GID з монтування.

Стратегія виправлення:

• Задайте власність через опції монтування (наприклад, uid=1000,gid=1000).
• Виберіть відповідні umask, fmask, dmask.
• Якщо вам потрібна реальна Unix-семантика, скопіюйте дані на ext4/xfs/btrfs.

ZFS: властивості dataset можуть збивати з пантелику

ZFS зберігає Unix-власність нормально, але має властивості dataset, що впливають на поведінку — особливо при змішуванні Linux-хостів, контейнерів і різних режимів ACL. ACLtype та налаштування xattr можуть змінювати, як поводяться дозволи і як інструменти їх звітують.

Для ZFS дійте як із реальною продуктивною файловою системою (бо так воно і є):

• Перевірте mountpoints dataset і переконайтесь, що ви виправляєте правильний шлях.
• Перевірте режим ACL, якщо бачите заплутані результати.
• Не виконуйте рекурсивний chown через datasets, якщо ви цього не планували.

Контейнери й user namespaces: UID 1000 всередині не той, що зовні

Переінсталяція + контейнери — це те, де люди втрачають половину дня. З user namespaces UID 0 контейнера може мапитись на ненульовий діапазон UID на хості. Ваші файли можуть виглядати як «власник 100000» або подібні числа на хості. Це не пошкодження; це мапування.

Точка прийняття рішення:

• Якщо ви хочете, щоб хост і контейнер спільно використовували каталоги на запис, спроектуйте мапування свідомо.
• Не змінюйте власність хостових шляхів навмання, щоб «виправити» права контейнера; ви можете зламати мапування і послабити безпеку.

Жарт №1: Контейнери — це круто, доки не виявиться, що файл належить «100000» і ви починаєте торгуватися з ядром, ніби воно відчуває.

Три корпоративні міні-історії з реального життя

Міні-історія 1: Інцидент, спричинений хибним припущенням

У компанії була невелика група build-агентів. Нічого екзотичного: Linux VM, кожна з локальним SSD для робочого простору і NFS-монтуванням для кешу артефактів. Після циклу патчів відбулася рутинна оновлення образу. Новий ОС, той самий hostname. Усі припускали, що обліковий запис користувача залишиться «такий самий».

Він не був. Автоматизація створила користувача збірки після кількох системних облікових записів, і він опинився з іншим UID, ніж раніше. Локально це не дуже вплинуло — свіжий робочий простір, нові файли. На NFS проблема проявилася миттєво. Каталог кешу належав старому UID. Користувач збірки раптом не міг записувати артефакти, тож завдання почали падати так, ніби це були випадкові помилки компіляції і таймаути. Логи CI були повні шуму і майже без повідомлень «permission denied», бо інструменти збірки робили повторні спроби, відступали і падали пізніше.

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

Виправлення було простим і трохи принизливим: запровадити консистентний UID для користувача збірки в образах і chown каталогу кешу NFS на цей UID/GID. Урок виявився ціннішим за простій: якщо ресурс спільний між хостами, числова ідентичність має розглядатися як API, а не випадковість.

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

Інша організація намагалася пришвидшити повторне створення робочих станцій. Вони перестали копіювати домашні каталоги і замість цього перемістили їх на додатковий диск, який переживе перевстановлення ОС. «Просто змонтуємо його як /home після перевстановлення. Легко.»

Було легко — для перших кількох ноутбуків. Потім новий реліз ОС змінив поведінку створення користувачів, і перший створений користувач тепер стабільно займав UID 1000, навіть коли IT хотіло іншу схему. Деякі ноутбуки опинилися з домашніми каталогами, що належали UID 1005, новий користувач — UID 1000, а середовище робочого столу вирішувало цю невідповідність творчими способами. Цикли входу. Зламані keyring. Додатки не могли створювати конфігураційні файли. Люди втрачали півдня, а служба підтримки набула нервового тіку.

Вони «оптимізували», пропустивши крок міграції даних, але також пропустили частину, де визначається, як ідентичність зберігається з часом. Насправді виправлення полягало в тому, щоб закріпити передбачуване присвоєння UID/GID в процесі провізії (або використовувати централізовану ідентичність), і додати явний етап погодження власності після інсталяції, який був би аудитуємим. Оновлений процес займав кілька хвилин на машину. Він заощадив години хаосу.

Жарт №2: Нічого не швидше за пропуск кроків — поки ви не порахуєте весь час на відмотування їх назад.

Міні-історія 3: Сумна, але правильна практика, що врятувала ситуацію

Одна фінансова компанія (та, що любить трейли аудиту) працювала в змішаному середовищі: bare metal, VM і кілька великих файлових серверів. У них була проста, нудна політика: усі людські користувачі були в центральному каталозі, а локальне створення користувачів на серверах було небажаним, якщо не було вагомих причин. Розподіл UID/GID був консистентним на всіх Linux-системах.

Одного вікенду їм довелося перевстановити хост, який був вузлом обробки даних. Перевстановлення пройшло гладко, і вузол повернувся до кластера без драм. Жодних помилок прав доступу. Жодних аварійних chown. Жодної «nobody» власності. Оператор, який це зробив, нормально спав тієї ночі, що в нашій професії вважається перемогою.

Причина була не героїчною. Це була політика. Хост приєднався до сервісу директорії, отримав ті самі числові ідентичності, і спільне сховище поводилося так само, як і раніше. Їхній change management виглядав болісно консервативним у звичайні часи. У стресі це спрацювало як страховка.

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

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

1) «chmod 777 не допоміг»

Симптом: Ви виконали chmod -R 777 і все одно не можете писати, або деякі програми продовжують падати.

Корінь проблеми: Невідповідність власності (UID/GID), монтування тільки для читання, deny в ACL, незмінний біт або відмова SELinux/AppArmor.

Виправлення: Перевірте числову власність за допомогою ls -ln, режим монтування — findmnt, ACL — getfacl, атрибути — lsattr, і SELinux логами через ausearch. Потім використовуйте chown або виправляйте шар монтування/безпеки.

2) «chown: Operation not permitted» на зовнішньому диску

Симптом: chown падає на змонтованому диску.

Корінь проблеми: Файлова система не підтримує Unix-власність (FAT), або ви на CIFS/NTFS з обмеженим мапінгом.

Виправлення: Використовуйте опції монтування (uid=, gid=, dmask=, fmask=), або скопіюйте дані на Linux-native файлову систему, якщо потрібна реальна власність.

3) «Все належить nobody:nogroup» на NFS

Симптом: UID/GID показує 65534; доступ заблоковано.

Корінь проблеми: Невідповідність відображення ідентичності NFS (клієнт і сервер не погоджують), або відсутня/неправильна конфігурація idmap.

Виправлення: Забезпечте консистентність UID/GID між системами (центральний каталог допоможе), перевірте домен idmapping NFSv4 і перемонтуйте після змін.

4) «Я можу читати, але не писати; я — власник файлу»

Симптом: Виглядає, що власник правильний, біти дозволяють запис, але все одно відмова.

Корінь проблеми: Маска ACL обмежує, файлова система в режимі тільки для читання, встановлено незмінний атрибут, або SELinux відмовляє.

Виправлення: getfacl для маски, findmnt для ro, lsattr для i, і перевірка логів SELinux/AppArmor.

5) «Після виправлення власності SSH-ключі перестали працювати»

Симптом: Вхід по SSH не вдається з повідомленнями про права.

Корінь проблеми: Директорія .ssh або файли ключів стали занадто дозволеними (група має право на запис), або залишився неправильний власник.

Виправлення: Забезпечте ~/.ssh 0700, приватні ключі 0600, і власність, що відповідає користувачу.

6) «Моя сесія робочого столу застрягла в циклі входу»

Симптом: Ви заходите, екран мигкає, ви повертаєтесь на екран входу.

Корінь проблеми: Домашня теĸа недоступна для запису для сеансових файлів (невідповідність власності), або .Xauthority/.ICEauthority належать іншому UID.

Виправлення: Виправте власність домашньої теĸи, потім видаліть/пересоздайте authority-файли за потреби.

7) «Я виправив /home, але якась підтеĸа все ще забороняє доступ»

Симптом: Більшість працює; один проектний каталог — ні.

Корінь проблеми: Інший UID/GID володіє тим піддеревом, або це точка монтування куди інакше, або там є строгі ACL.

Виправлення: Використовуйте find ... -xdev, щоб не переходити межі монтувань, і перевірте конкретну директорію за допомогою ls -ldn і getfacl.

Чеклісти / покроковий план

План A: Ви перевстановили Linux і змонтували старий ext4 домашній каталог

1. Визначте поточний UID/GID: id.
2. Визначте стару власність: ls -ldn /mnt/oldhome/you.
3. Підтвердьте, що ФС підтримує власність: findmnt -no FSTYPE,OPTIONS /mnt/oldhome.
4. Попередній перегляд масштабу: sudo find /mnt/oldhome/you -xdev -uid OLDUID | head.
5. Змініть власність з паском безпеки: sudo chown -R --from=OLDUID:OLDGID NEWUID:NEWGID /mnt/oldhome/you.
6. Повторно перевірте запис: створіть тестовий файл (touch).
7. Перевірте чутливі дозволи: нормалізуйте .ssh.
8. Якщо лишається дивина — перевірте ACL: getfacl.

План B: Спільне сховище або кілька хостів (NFS/кластери)

1. Зупиніться і вирішіть: чи хочете ви стабільні UID/GID між хостами? Ви маєте. Дійте як такі.
2. Виберіть авторитетний UID/GID для кожного людини/сервісного облікового запису.
3. Узгодьте ідентичності (директорія сервісів або сувора локальна політика).
4. Виправте власність на стороні сервера, де це доречно (особливо для NFS-експортів).
5. Перевірте з клієнта: ls -ln має показувати очікувані числові власники.
6. Закріпіть: додайте перевірки в provisioning, щоб підтверджувати UID/GID перед монтуванням спільних шляхів.

План C: Зовнішній диск у форматі NTFS/FAT

1. Підтвердьте тип ФС: findmnt -no FSTYPE,OPTIONS /mnt/drive.
2. Не боріться з chown: припускайте, що він не зберігатиметься.
3. Задайте мапінг при монтуванні: виберіть uid, gid, маски, які відповідають потребам.
4. Якщо потрібна Unix-семантика: копіюйте дані на ext4/xfs/btrfs і працюйте там.

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

• UID/GID зберігаються як числа на диску, бо ранні Unix-системи потребували компактних і швидких перевірок без рядкових пошуків.
• Класичний Unix використовував 16-бітні UID в ранніх реалізаціях; сучасні системи підтримують значно більші діапазони, але спадкові припущення все ще зʼявляються в інструментах.
• Користувач «nobody» — це конвенція, що використовується для відображення невідомих або неперевірених ідентичностей (зазвичай UID 65534), особливо в NFS-контекстах.
• POSIX ACL додавалися, щоб вирішити реальні багатокористувацькі проблеми, де модель власник/група/інші була замалою для вираження політик спільного доступу.
• Setgid на директоріях — старий трюк для співпраці, який і досі працює: нові файли успадковують групу директорії, зменшуючи випадки «чому група неправильна?».
• NFSv4 ввів сильнішу семантику ідентичностей і стан у порівнянні з NFSv3, але неправильне idmapping може бути гіршим за просту числову поведінку.
• FAT передував Unix-права і не має концепції власника файлу; Linux має проектувати модель дозволів зверху.
• SELinux виник із досліджень безпеки та потреб підприємств, щоб застосовувати обовʼязкові контролі доступу поза дискреційними Unix-правами, тому він може перевершити ваш «правильний» chmod/chown.
• User namespaces змінили правила гри, дозволивши контейнерам ремапити UID, що покращує ізоляцію, але робить власність файлів на хості дивною.

FAQ

1) Чому після перевстановлення змінився доступ, якщо моє імʼя користувача те саме?

Тому що файлова система зберігає числові UID/GID, а не імʼя користувача. Після перевстановлення імʼя може відповідати іншому UID/GID, тож ядро вважає вас іншим власником.

2) Чи краще змінити UID нового користувача або зробити chown файлів?

Якщо це одиночна машина з локальним сховищем, зазвичай простіше зробити chown файлів на новий UID. Якщо сховище спільне між машинами, краще зберігати стабільні UID і змінити обліковий запис, щоб відповідати їм.

3) Чому chmod не вирішує «Permission denied» у моєму випадку?

Бо ви не є власником (числово). chmod змінює біти режиму, але не власність. Також ACL/SELinux/монтування тільки для читання можуть блокувати доступ.

4) Який найбезпечніший спосіб зробити рекурсивне виправлення власності?

Використовуйте chown -R --from=OLDUID:OLDGID NEWUID:NEWGID на конкретній директорії і попередньо перегляньте за допомогою find -uid OLDUID. Додавайте -xdev, щоб не переходити межі монтувань.

5) Я запустив chown -R і тепер щось зламалося. Що могло статися?

Поширені втрати: змонтовані піддиректорії (ви змінили власність іншої файлової системи), директорії додатків, які очікують конкретних сервісних облікових записів, і дозволи SSH-ключів. Перевірте точки монтування і сервісних користувачів.

6) Мої файли на NTFS. Чи можу я назавжди виправити власність?

Не в Unix-сенсі. Зазвичай ви мапите власність через опції монтування. Якщо потрібна per-file Unix-власність і режими, перемістіть дані на Linux-native файлову систему.

7) Чому мої файли показані як «nobody» на NFS?

Відображення ідентичностей між клієнтом і сервером не збігається, або UID/GID невідомі на одній зі сторін. Виправте, зробивши ідентичності консистентними або налаштувавши idmapping NFS.

8) Я володію директорією, але не можу писати. Що ще блокує запис?

Монтування тільки для читання, обмеження маски ACL, незмінні атрибути, політика SELinux/AppArmor або квоти. Діагностуйте за допомогою findmnt, getfacl, lsattr і логів безпеки.

9) Чи можна зовсім уникнути цього наступного разу?

Так: зберігайте UID стабільними (централізована ідентичність або політика провізії), документуйте розподіл UID/GID для сервісних облікових записів і перевіряйте монтування та власність після відновлення перед поверненням системи користувачам.

Висновок: наступні кроки, які можна зробити сьогодні

Якщо ви бачите «Access denied» на власних файлах після перевстановлення, перестаньте трактувати це як таємницю прав. Зазвичай це зсув ідентичності. Числа змінилися. Ядро робить саме те, що йому наказали.

Зробіть це наступним:

1. Запустіть id і ls -ln на проблемному шляху. Підтвердіть невідповідність UID/GID.
2. Підтвердьте тип файлової системи та прапори монтування за допомогою findmnt. Виключіть монтування лише для читання та «фейкову» власність.
3. Виправте власність за допомогою chown -R --from=OLDUID:OLDGID NEWUID:NEWGID на найменшому піддереві, яке має сенс.
4. Якщо проблема лишається, перевірте ACL і SELinux/AppArmor перш ніж застосовувати «chmod-терапію».
5. Для спільних середовищ зробіть консистентність UID/GID політикою, а не надією.

Коли ви зробите це кілька разів, ви почнете упізнавати «запах» цієї проблеми за секунди: те саме імʼя користувача, неправильні числа і файловa система, що ввічливо відмовляється брати участь у вашій ностальгії.