Для восстановления некоторых удаленных файлов из файловой системы ext4 на ноутбуке с Ubuntu 18.04.5 я использовал PhotoRec/StartDisk.
Сначала я позволил ей выполнить свою работу над всем разделом, всеми расширениями. И PhotoRec удалось восстановить пару миллионов файлов. Поскольку восстановленные файлы называются по-разному и не расположены в папках, как это было, трудно найти интересующие файлы.
Затем я снова запустил PhotoRec только с одним типом файла: sqlite
, но я попросил его также искать поврежденные файлы.
Некоторое время он работает хорошо, но затем уведомил меня о том, что мне не хватает памяти, и предложил мне очистить мусорное ведро. Я удалил файлы из корзины и возобновил поиск.
Вскоре система полностью исчерпала память в точку, где не удалось создать новую папку.
Я удалил первоначально восстановленные файлы (все из всего раздела). Но на самом деле они не удалялись. Если быть точным: файлы исчезли. Но, пространство не освободилось.
Я думал, что перезагрузка освободит пространство. Но теперь я не могу даже загрузиться в Ubuntu:
я могу перейти к Advanced Options
> > Ubuntu (режим восстановления)
.
У меня есть несколько вариантов. Один из них: system-summary
, говорит мне, что действительно мой диск заполнен на 100%.
Теперь мой инстинкт - запустить чисто
. Но, как говорится: один раз укусил, дважды застенчивый - я не совсем уверен, что это правильно. В нем говорится: «Продолжение будет повторно монтировать вашу/filesystem в режиме чтения/записи и монтировать любую другую файловую систему, определенную в /etc/fstab
».
/etc/fstab
? Похоже, что восстановленные файлы с Shift + Delete
по-прежнему хранятся в .local/share/Trash/expunged
. Почему они все еще здесь?
Недавно я переустановил Ubuntu 20.04 и сделал раздел/var слишком маленьким. Чтобы избежать необходимости переустановки, я решил просто переместить большую папку/var/cache на другой диск и синхронизировать ее, но у меня, похоже, нарушены права собственности и/или разрешения.
Я пытался рекурсивно изменить права собственности на _apt для папки/var/cache/apt и аналогичные для man для/var/cache/man, но при установке с apt она все еще работает неправильно.
Вместо symlink, установка раздела на /var/cache
скорее всего достигнет ваших целей. Что касается файловых разрешений, то лучше не гадать с помощью этих вещей. Это то, что у меня есть в каталоге /var/cache
(ваш может отличаться):
drwxr-xr-x 19 root root 4096 5月 10 2020 ./
drwxr-xr-x 15 root root 4096 2月 4 2020 ../
drwxr-xr-x 3 root root 4096 4月 17 2019 PackageKit/
drwxr-xr-x 3 root root 4096 2月 4 2020 apache2/
drwxr-xr-x 5 root root 4096 10月 24 2019 app-info/
drwxr-xr-x 3 root root 4096 7月 2 2019 apparmor/
drwxr-xr-x 3 root root 4096 1月 27 09:46 apt/
drwxr-xr-x 2 root root 4096 4月 17 2019 cracklib/
drwxrwx--- 3 root lp 4096 1月 27 00:00 cups/
drwxr-xr-x 2 root root 4096 1月 20 06:45 debconf/
drwxr-xr-x 2 root root 4096 4月 17 2019 dictionaries-common/
drwxr-xr-x 2 root root 24576 1月 26 17:01 fontconfig/
drwxr-xr-x 2 root root 4096 1月 27 06:12 fwupd/
lrwxrwxrwx 1 root root 16 5月 10 2020 fwupdmgr -> private/fwupdmgr
drwxr-xr-x 2 root root 4096 3月 16 2019 gdm/
drwx------ 2 root root 4096 1月 13 21:59 ldconfig/
drwxr-xr-x 36 man man 4096 1月 27 00:00 man/
-rw-r--r-- 1 root root 160 9月 7 08:00 motd-news
drwxr-xr-x 3 root root 4096 2月 4 2020 postgresql/
drwx------ 3 root root 4096 5月 10 2020 private/
drwxr-xr-x 3 root root 4096 1月 26 17:41 snapd/
Однако даже с этим списком вы не можете слепо задать разрешения. В качестве примера можно привести /var/cache/cups
, который используется для печати, где разные файлы имеют разные разрешения:
drwxrwx--- 3 root lp 4096 1月 27 00:00 ./
drwxr-xr-x 19 root root 4096 5月 10 2020 ../
-rw-r--r-- 1 root root 2534 1月 27 00:00 Canon_TS8230.data
-rw-r--r-- 1 root root 280 1月 27 00:00 Canon_TS8230.strings
-rw-r--r-- 1 root root 387 1月 15 2020 cups-browsed-options-canon_ts8230
-rw-r--r-- 1 root root 406 1月 27 00:00 cups-browsed-options-Canon_TS8230
-rw-r----- 1 root lp 64 1月 27 00:00 job.cache
-rw-r----- 1 root lp 64 1月 26 00:00 job.cache.O
-rw-r--r-- 1 root root 7 1月 27 00:00 org.cups.cupsd
-rw------- 1 lp lp 6818188 5月 9 2020 ppds.dat
-rw-r--r-- 1 root root 308 5月 9 2020 ppd-updates
drwxrwxr-x 2 root lp 4096 2月 16 2019 rss/
Поскольку вы недавно переустановили ОС, скорее всего, у вас уже есть много важных файлов, резервная копия которых безопасно хранится. Протрите машину, переустановите, продолжайте. Если в будущем вам действительно понадобится разместить таблицы ядра на разных разделах/устройствах хранения, используйте точки монтирования для сохранения головной боли