Ошибка ввода / вывода gcsfuse

Я получаю сообщение об ошибке ввода / вывода, когда пытаюсь создать каталог или файл в корзине облачного хранилища Google, смонтированной в каталоге Linux (Ubuntu 15.10).

Шаги, которые я сделал:

  • Создан пользовательский перевод
  • Создал /mnt/backups каталог и запустил chown -R transfer /mnt/backups
  • Как пользователь перенёс, запустил gcsfuse --implicit-dir backup01-bucket /mnt/backups. Файловая система смонтирована успешно
  • Запускаем mkdir test и получаем ошибку mkdir: cannot create directory test: Input/output error

Я что-то пропустил? Я пытаюсь передать ftp-файлы на сервер и хранить их в хранилище Google, а не в локальном хранилище.

Обновить Я изменил команду, чтобы получить некоторую отладочную информацию:

gcsfuse --implicit-dirs --foreground --debug_gcs --debug_fuse backup01-bucket /mnt/backups

Затем запустил mkdir /mnt/backups/test как transfer пользователь.

Вышла следующая информация о клопах:

fuse_debug: Op 0x00000060        connection.go:395] <- GetInodeAttributes (inode 1)
fuse_debug: Op 0x00000060        connection.go:474] -> OK
fuse_debug: Op 0x00000061        connection.go:395] <- LookUpInode (parent 1, name "test")
gcs: Req             0x3a: <- StatObject("test/")
gcs: Req             0x3b: <- ListObjects()
gcs: Req             0x3c: <- StatObject("test")
gcs: Req             0x3c: -> StatObject("test") (53.375107ms): gcs.NotFoundError: googleapi: Error 404: Not Found, notFound
gcs: Req             0x3b: -> ListObjects() (59.061271ms): OK
gcs: Req             0x3a: -> StatObject("test/") (71.666112ms): gcs.NotFoundError: googleapi: Error 404: Not Found, notFound
fuse_debug: Op 0x00000061        connection.go:476] -> Error: "no such file or directory"
fuse_debug: Op 0x00000062        connection.go:395] <- MkDir
gcs: Req             0x3d: <- CreateObject("test/")
gcs: Req             0x3d: -> CreateObject("test/") (22.090155ms): googleapi: Error 403: Insufficient Permission, insufficientPermissions
fuse_debug: Op 0x00000062        connection.go:476] -> Error: "CreateChildDir: googleapi: Error 403: Insufficient Permission, insufficientPermissions"
fuse: 2016/04/04 06:51:02.922866 *fuseops.MkDirOp error: CreateChildDir: googleapi: Error 403: Insufficient Permission, insufficientPermissions
2016/04/04 06:51:08.378100 Starting a garbage collection run.
gcs: Req             0x3e: <- ListObjects()
gcs: Req             0x3e: -> ListObjects() (54.901164ms): OK
2016/04/04 06:51:08.433405 Garbage collection succeeded after deleted 0 objects in 55.248203ms.

Примечание. Если я создам каталог в веб-консоли, я могу видеть этот каталог в порядке.


person user1476207    schedule 03.04.2016    source источник
comment
Не могли бы вы запустить gcsfuse с --foreground и исправить свой вопрос с помощью вывода журнала? Если ничего полезного нет, попробуйте также --debug_gcs и / или --debug_fuse.   -  person jacobsa    schedule 04.04.2016
comment
Я обновил вопрос, указав отладочную информацию. Спасибо.   -  person user1476207    schedule 04.04.2016


Ответы (5)


Судя по Insufficient Permission ошибкам в результатах отладки, gcsfuse не имеет достаточных разрешений для вашей корзины. Вероятно, у него есть доступ только для чтения.

Обязательно прочтите документацию по учетным данным для gcsfuse. В частности, если вы используете учетную запись службы на виртуальной машине GCE, обязательно настройте виртуальную машину с storage-full областью доступа.

person jacobsa    schedule 05.04.2016
comment
Спасибо! К сожалению, мне пришлось воссоздать виртуальную машину, чтобы включить API. Не удалось найти способ изменить хранилище на чтение-запись на существующей виртуальной машине. - person user1476207; 08.04.2016
comment
Да, насколько мне известно, это невозможно изменить. - person jacobsa; 09.04.2016
comment
Хорошие новости: с 17 декабря 2016 г. можно изменять разрешения для остановленной виртуальной машины. См. googlecloudplatform.uservoice.com/forums/302595-compute-engine/. Вы также можете изменить разрешения для каждого API, например, продолжить запрещать доступ к BigQuery, но заполнить хранилище. - person Spotlight; 15.07.2017
comment
Я только что успешно изменил доступ к API хранилища на остановленном экземпляре, чтобы решить эту проблему. Обратите внимание, что чтения / записи НЕ было достаточно. Мне пришлось предоставить полный доступ к хранилищу для записи поверх предохранителя gcs. - person jorfus; 19.12.2017
comment
спасибо, я нашел этот рабочий GOOGLE_APPLICATION_CREDENTIALS = / root / mykey.json gcsfuse ... - person James Tan; 11.05.2018

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

  1. Создайте сервисный аккаунт
  2. Создайте ключ для учетной записи службы и загрузите файл JSON.
  3. Назначьте соответствующую роль учетной записи службы
  4. Предоставьте соответствующие разрешения учетной записи службы в корзине.
  5. Загрузите учетные данные JSON для учетной записи службы на виртуальную машину.

Наконец, определите переменную среды, которая содержит путь к учетным данным учетной записи службы при вызове gcsfuse из командной строки:

GOOGLE_APPLICATION_CREDENTIALS=/root/credentials/service_credential_file.json gcsfuse bucket_name /my/mount/point

Используйте параметр key_file, чтобы сделать то же самое в fstab. Оба эти параметра задокументированы в документации по учетным данным gcsfuse. . (РЕДАКТИРОВАТЬ: эта опция задокументирована, но не сработает для меня.)

Интересно, что вам нужно использовать переменную среды или параметр key_file, даже если вы настроили учетную запись службы на виртуальной машине, используя:

gcloud auth activate-service-account --key-file /root/credentials/service_credential_file.json

По какой-то причине gcsfuse игнорирует активную учетную запись с учетными данными.

Использование области storage-full при создании виртуальной машины имеет последствия для безопасности и стабильности, поскольку позволяет этой виртуальной машине иметь полный доступ ко всем сегментам, принадлежащим одному и тому же проекту. Должен ли ваш сервер хранения файлов действительно иметь возможность перезаписывать журналы в ведре регистрации или читать резервные копии базы данных в другом ведре?

person Craig Finch    schedule 19.08.2016
comment
использование аргумента --key-file не помогло мне. Файловая система монтировалась, но эта операция зависла. Первым делом сработало как шарм, что GOOGLE_APPLICATION_CREDENTIALS = .. - person Prasad; 25.01.2020

Эта проблема связана с отсутствием файла учетных данных.

перейдите на https://cloud.google.com/docs/authentication/production

Создание учетной записи службы

  • После создания учетной записи вы получите файл json.
  • загрузите свой json на экземпляр виртуальной машины.
  • # P4 #
    # P5 #
    # P6 #
  • $ mount -a

Перейдите по этой ссылке

https://github.com/GoogleCloudPlatform/gcsfuse/blob/master/docs/mounting.md#credentials

person Abhimanyu Kmar    schedule 22.11.2019

Эта проблема также может возникнуть, если вы установили некоторые политики / правила хранения в этом сегменте. Как и у меня, я также получал ту же ошибку ввода / вывода, когда пытался обновить любой файл в смонтированной папке, основная причина заключалась в том, что я добавил политику хранения, чтобы не удалять ни один файл до 1 месяца.

person Mukesh Rajput    schedule 11.04.2020

Я периодически сталкивался с этой проблемой, поэтому решил, что поделюсь тем, что нашел:

Я использую minikube для разработки и GCP для производства.

У меня есть следующий крючок жизненного цикла postStart:

lifecycle:
  postStart:
    exec:
      command: ['gcsfuse', '-o', 'allow_other', 'bucket', 'path']

Локально я настроил разрешения, выполнив эти две команды перед созданием модуля:

$ gcloud auth login
$ minikube addons enable gcp-auth

Удаленно при создании кластера я включил такие разрешения:

gcloud_create_cluster:
    gcloud container clusters create cluster \
    --scopes=...storage-full...

Во время разработки я обнаружил, что обновляю / переопределяю файлы по 1 минуте каждый. Поскольку моя политика хранения была установлена ​​на 60 секунд, любые изменения или удаления в это время были запрещены. Решение было просто уменьшить.

введите описание изображения здесь

Это не окончательное решение, но, надеюсь, кто-то другой сочтет его полезным.

person Olshansk    schedule 29.11.2020