Извлечение линий «Доступ запрещен»
1st thing to do: BACKUP YOUR HOME Я не могу сказать, что это громче ... в основном отменяющее шифрование эквивалентно сбросу (rm -rf) вашего дома, который на самом деле скрыт монтированием.
2-й шаг: выйти из любого диспетчера рабочего стола и перейти на виртуальную консоль (CTRL-ALT-F1)
Наконец: для деталей:
ecryptfs-setup-private --undo
В случае, если вы хотите чтобы удалить настройку Private Directory eCryptfs, вам нужно будет очень тщательно выполнить следующие действия вручную:
Получить вашу точку монтирования в личном каталоге PRIVATE= cat ~/.ecryptfs/Private.mnt 2>/dev/null || echo $HOME/Private Убедитесь, что вы переместили все релевантные данные из вашего каталога $PRIVATE Отключите ваш зашифрованный частный каталогecryptfs-umount-private
chmod 700 $PRIVATE
rm -rf $PRIVATE ~/.Private ~/.ecryptfs
sudo apt-get remove ecryptfs-utils libecryptfs0
Я бы сказал, что шаг 5 немного не прав: нет необходимости удалять $PRIVATE, что было для меня моим домом ....
После удаления .Private и .ecryptfs , просто восстановите свой дом:]
6 ответов
То, что вы пробовали, не работает, потому что вывод access denied является ошибкой и отправляется на STDERR вместо STDOUT, который передается по каналу grep.
Вы можете избежать этих ошибок, перенаправив только STDERR
find /home -iname "*.pdf" 2>/dev/null
Или, как прокомментировал Дэвид Фёрстер, мы можем более кратко закрыть STDERR
find /home -iname "*.pdf" 2>&-
Однако я подозреваю, что вы на самом деле хотите только искать свой дом, а не других пользователей, поэтому возможно, вы действительно хотите
find ~ -iname "*.pdf"
Если это вызывает ошибки, могут быть некоторые неправильные владельцы в вашей локальной конфигурации, которые вы должны исследовать.
-
1Grrr, почему люди всегда избивают меня на 30 секунд? : \ – Android Dev 9 August 2017 в 14:31
-
2find: "/home/ihsan/.gvfs": доступ запрещен: "/home/ihsan/.dbus": доступ запрещен, для команды ~ – solfish 9 August 2017 в 14:34
-
3что-то не так? да, я также хочу, чтобы к домашнему каталогу других пользователей, который также был создан мной для тестирования – solfish 9 August 2017 в 14:34
-
4@solfish Насколько я знаю, эти файлы должны принадлежать вам. Вы можете захотеть sudo chown $USER: ~/.gvfs ~/.dbus – Zanna 9 August 2017 в 14:37
-
5Достаточно закрыть stderr с помощью 2>&-. GNU find не прекращается, если он пытается записать сообщения об ошибках в дескриптор дисфункционального файла. Для проблем с владением sudo chown -R $USER: ... было бы более эффективным в случае большего количества файлов, которые не принадлежат $USER. – David Foerster 9 August 2017 в 16:56
То, что вы пробовали, не работает, потому что вывод access denied является ошибкой и отправляется на STDERR вместо STDOUT, который передается по каналу grep.
Вы можете избежать этих ошибок, перенаправив только STDERR
find /home -iname "*.pdf" 2>/dev/null
Или, как прокомментировал Дэвид Фёрстер, мы можем более кратко закрыть STDERR
find /home -iname "*.pdf" 2>&-
Однако я подозреваю, что вы на самом деле хотите только искать свой дом, а не других пользователей, поэтому возможно, вы действительно хотите
find ~ -iname "*.pdf"
Если это вызывает ошибки, могут быть некоторые неправильные владельцы в вашей локальной конфигурации, которые вы должны исследовать.
То, что вы пробовали, не работает, потому что вывод access denied является ошибкой и отправляется на STDERR вместо STDOUT, который передается по каналу grep.
Вы можете избежать этих ошибок, перенаправив только STDERR
find /home -iname "*.pdf" 2>/dev/null
Или, как прокомментировал Дэвид Фёрстер, мы можем более кратко закрыть STDERR
find /home -iname "*.pdf" 2>&-
Однако я подозреваю, что вы на самом деле хотите только искать свой дом, а не других пользователей, поэтому возможно, вы действительно хотите
find ~ -iname "*.pdf"
Если это вызывает ошибки, могут быть некоторые неправильные владельцы в вашей локальной конфигурации, которые вы должны исследовать.
Отказано в доступе, вероятно, печатается на stderr, а не на stdout.
Попробуйте следующее:
find /home -iname "*.pdf" 2>&1 | grep -v "access denied"
2>&1 перенаправляет вывод с stderr на stdout, так что grep -v может выполнять свою работу. (По умолчанию | только трубы stdout, а не stderr.)
-
1но для этого 2 & gt; & amp; 1 означает, что если stderr существует, отправляйте на stdout? – solfish 9 August 2017 в 14:41
-
2
-
3что я не понимаю, до " " " " как выход; мы получили просто stderr? и после " " " в качестве ввода мы получили это – solfish 9 August 2017 в 14:45
-
4@solfish Ну, я столкнулся с этой проблемой около полутора лет назад, и я смог исправить ее, используя другой метод . Но затем комментарий ниже моего ответа предложил просто использовать 2>&1 ... Я не эксперт по bash, поэтому, если это неверно, тогда, пожалуйста, скажите так :) – Android Dev 9 August 2017 в 14:52
-
5
Отказано в доступе, вероятно, печатается на stderr, а не на stdout.
Попробуйте следующее:
find /home -iname "*.pdf" 2>&1 | grep -v "access denied"
2>&1 перенаправляет вывод с stderr на stdout, так что grep -v может выполнять свою работу. (По умолчанию | только трубы stdout, а не stderr.)
Отказано в доступе, вероятно, печатается на stderr, а не на stdout.
Попробуйте следующее:
find /home -iname "*.pdf" 2>&1 | grep -v "access denied"
2>&1 перенаправляет вывод с stderr на stdout, так что grep -v может выполнять свою работу. (По умолчанию | только трубы stdout, а не stderr.)
-
1но для этого 2 & gt; & amp; 1 означает, что если stderr существует, отправляйте на stdout? – solfish 9 August 2017 в 14:41
-
2
-
3что я не понимаю, до & quot; & quot; & quot; & quot; как выход; мы получили просто stderr? и после & quot; & quot; & quot; в качестве ввода мы получили это – solfish 9 August 2017 в 14:45
-
4@solfish Ну, я столкнулся с этой проблемой около полутора лет назад, и я смог исправить ее, используя другой метод . Но затем комментарий ниже моего ответа предложил просто использовать 2>&1 ... Я не эксперт по bash, поэтому, если это неверно, тогда, пожалуйста, скажите так :) – Android Dev 9 August 2017 в 14:52
-
5