Ни один из этих каталогов не имеет разрешения на выполнение. Согласно предоставленной вами информации, вы пытались смонтировать каталог как rwи ro. Вам нужно будет смонтировать файловую систему как rwx. Однако ваша проблема может быть связана с тем, как права доступа к файловой системе были искажены при восстановлении данных.

Похоже, что другие люди, столкнувшиеся с вашей проблемой, используют QNAP в среде Windows Active Directory. Это сообщение на форуме посвящено этой проблеме и может пролить немного света, если ваша среда привязана к Windows Active Directory. Это еще один пост , связанный с Windows. Я также нашел этот пост . Не уверен, что они применимы, но они появляются при поиске по вашей проблеме.

Я ссылаюсь на Arch Linux Wiki по ecryptfs и Arch Linux Wiki по монтированию NTFS. Вот ссылки на QNAP Wiki о правах доступа к подпапкам и о категориях восстановления данных . Они также должны помочь предоставить дополнительную информацию о том, как устранить проблему.

Повторно -смонтировать файловую систему и исправить разрешения

Я бы начал все сначала. Перезагрузите и перемонтируйте свои системы. Если команда mount работала раньше, чтобы позволить вам успешно расшифровать вашу файловую систему и смонтировать, вам необходимо изменить права доступа к каталогу как root (sudo )на:

chmod go= [root directory name]

Вы также можете попробовать смонтировать ecryptfs вручную с помощью обёртки:

ecryptfs-mount-private Path/To/File/System

Опять же chmodможет помочь и после этого шага, если разрешения по-прежнему отсутствуют. Вам будет предложено ввести пароль монтирования для ваших ecryptfs с помощью приведенной выше команды.

Если вы можете прокомментировать какие-либо дополнительные проблемы, которые у вас есть, я могу обновить ответ с более подходящими решениями. Я полагаю, что ваша проблема может быть связана с восстановлением искаженных данных (. Чтобы решить ее, вам нужно будет следовать руководству о том, как QNAP рекомендует выполнять восстановление данных ), или она может быть связана с настройками списка контроля доступа NFS или NTFS, предотвращающими надлежащие разрешения. Это должно быть связано только в том случае, если ваша среда также привязана к Windows. Если у кого-то есть какие-либо исправления, чтобы добавить, я был бы очень признателен. Удачи!

У меня была аналогичная проблема из-за неисправного оборудования, но она не была на QNAP, поэтому она может быть неприменима.

Тем не менее, я помню тот же странный lsвывод.

Что я сделал, так это просто смонтировал раздел как доступный для чтения/записи, а затем принудительно установил права собственности и разрешения. Я помню, что мне пришлось сделать это дважды, но я не помню причины (возможно, я что-то опечатал ).

chmod -R a+rwx /mnt/md3/documents/Secure
chown -R admin:administrators /mnt/md3/documents/Secure

У меня также были некоторые проблемы со списками контроля доступа, которые решались таким же образом.

К счастью, это был раздел с документами, и я не торопился, мне просто не хотелось делать медленное восстановление из резервных копий.

Вы можете попробовать с одним файлом или одним каталогом и посмотреть, применимо ли это.

Предполагая, что монтирование и fsck прошли нормально, это означает, что ваши данные можно использовать. Однако сделайте резервную копию несмонтированного зашифрованного контейнера и, если это вообще возможно, смонтируйте и поэкспериментируйте с копией .

После восстановления сохраните все файлы на резервном диске, выполните полное восстановление заводских настроек на QNAP (, возможно, удалив диски,достаточно отформатировать их и поместить обратно, -QNAP должен повторно инициализировать их самостоятельно. Я знаю, что устройства Synology и Terastore делают ), а затем помещают файлы обратно. Таким образом, вы будете знать, что можете снова доверять файловой системе QNAP.