Вопрос или проблема
Раньше я просто нажимал клавишу Delete на выбранных файлах в Nautilus, и это отправляло файл(ы) в корзину без подтверждения. Это было очень удобно.
Позже я решил, что моя корзина может содержать конфиденциальные файлы, и поэтому переместил ее в папку Private с использованием eCryptfs и создал в ее месте символическую ссылку ~/.local/share.
После этого, когда я нажимаю Delete на файлах, которые находятся внутри eCryptfs, поведение соответствует ожиданиям, без проблем. С другой стороны, когда я пытаюсь удалить файлы в своем домашнем каталоге, но вне eCryptfs, я получаю следующее сообщение:
Такое же поведение наблюдается при удалении элементов с другого диска…
Существует ли способ автоматически помещать файлы в мою зашифрованную корзину, даже если они принадлежат другому/незашифрованному диску/монтированию?
Если это действительно невозможно, то возможно ли иметь две Корзины? Одну для зашифрованных файлов и другую для незашифрованных?
Когда вы перемещаете файлы в корзину с помощью Nautilus или gvfs-trash, они никогда не перемещаются на другой том. Они «переименовываются» в другую запись каталога (внутри директории корзины) на том же томе. Обратите внимание, что документация этой функции объясняет, что файлы не могут быть «переименованы» на разные тома или точки монтирования.
Это означает, что перемещение файла в корзину с зашифрованного тома (будь то eCryptFS, dm-crypt/LUKS или что-то другое, что требует от ядра монтирования чего-либо) никогда не приведет к расшифровке файла. Поэтому я не думаю, что целесообразно связывать ~/.local/share/Trash с чем-то под ~/Private. Вы можете проверить это следующими командами:
cd ~/Private
touch foobar.txt
gvfs-trash foobar.txt
ls -1 ~/.local/share/Trash/files/foobar.txt* ~/Private/.Trash-*/files/foobar.txt*
что должно дать вам что-то вроде:
ls: не удается получить доступ к /home/david/.local/share/Trash/files/foobar.txt*: Нет такого файла или каталога
/home/david/Private/.Trash-1000/files/foobar.txt
Интересно, что файл не отображается в моей виртуальной папке корзины:
$ gvfs-ls trash:// | grep -cwFe foobar.txt
0
(Хотя то же самое работает, когда я выполняю gvfs-trash ~/foobar.txt.)
По указанной выше причине я думаю, что невозможно с текущей реализацией gvfs-trash иметь корзину на другом томе, чем оригинальный том файла, отправленного в корзину.
В недавнем обновлении начиная с GNOME 47, была добавлена опция монтирования x-gvfs-trash.
Вот некоторые возможности монтирования:
- ecryptfs
sudo mount -t ecryptfs ~/Private ~/.Private -o x-gvfs-trash,key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yes
- BTRFS
sudo mount -t btrfs -o defaults,subvol=data,x-gvfs-trash <device> <folder>
/etc/fstab
UUID=<UUID> /home btrfs subvol=@home,ssd,noatime,compress=zstd,x-gvfs-trash 0 0
Ответ или решение
Проблема с перемещением файлов в корзину в Nautilus при использовании eCryptfs
Описание проблемы
Пользователь столкнулся с невозможностью перемещения файлов в корзину Nautilus, когда файлы находятся на различных накопителях/разделах, а корзина была перемещена в зашифрованную папку eCryptfs, расположенную в директории ~/Private. Эта ситуация возникает из-за особенностей реализации функции перемещения файлов в корзину, касающейся работы с монтированными файловыми системами.
Причины проблемы
Функция gvfs-trash, используемая Nautilus для работы с корзиной, по своей архитектуре требует, чтобы файлы были "переименованы" в директорию корзины на том же томе (разделе), на котором они изначально находились. Этот подход основан на системной функции rename, которая не позволяет производить подобные операции между разными разделами или монтированными файловыми системами.
Когда вы пытаетесь переместить файл, находящийся вне каталога eCryptfs, в корзину, Nautilus не может выполнить операцию переименования, поскольку целевая директория корзины находится на другом разделе. В итоге и возникает сообщение об ошибке: "Файл не может быть помещён в корзину".
Возможные решения
- Использование параметра x-gvfs-trash:
С недавнего времени в GNOME в версии 47 была добавлена поддержка монтирования с параметром x-gvfs-trash. Это позволит вам настраивать различные ваши разделы для полной совместимости с функциональностью корзины. Вот пример команды для монтирования eCryptfs с использованием этого параметра:
sudo mount -t ecryptfs ~/Private ~/.Private -o x-gvfs-trash,key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yesОбратите внимание, что для других файловых систем, например BTRFS, вы также можете использовать аналогичный подход:
sudo mount -t btrfs -o defaults,subvol=data,x-gvfs-trash <device> <folder>Или добавить параметр в файл /etc/fstab для автоматической монтирования при загрузке системы:
UUID=<UUID> /home btrfs subvol=@home,ssd,noatime,compress=zstd,x-gvfs-trash 0 0- Создание отдельной корзины для зашифрованных и незашифрованных файлов:
На текущий момент, с учетом ограничений реализации gvfs-trash, возможность создания двух независимых корзин (одной для зашифрованных и другой для незашифрованных файлов) не поддерживается нативно в Nautilus. Тем не менее, вы можете рассмотреть возможность использования скриптов или других файловых менеджеров, которые могут поддерживать подобную функциональность.
- Возможные альтернативы:
Если функциональность корзины не отвечает вашим требованиям, вы можете также рассмотреть использование командной строки Linux для удаления файлов:
rm -i <file>Команда rm позволяет вам удалять файлы без использования корзины, но требует осторожности, так как нет возможности восстановить удалённые таким образом файлы.
Заключение
Проблема с перемещением файлов в корзину Nautilus, находящуюся в зашифрованной папке eCryptfs, объясняется ограничениями текущей реализации gvfs-trash. Использование новых параметров монтирования и альтернативные методы могут помогать в оптимизации вашего рабочего процесса. Чтобы останавливаться на более безопасной и удобной для вас практике, всегда важно поддерживать данные в надежном состоянии и делать резервные копии перед их удалением.