2016-04-03 7 views
4

Ich erhalte einen Eingabe/Ausgabe-Fehler, wenn ich versuche, ein Verzeichnis oder eine Datei in einem Google Cloud Storage-Bucket zu erstellen, der auf einem Linux-Verzeichnis (Ubuntu 15.10) installiert ist.gcsfuse Eingabe-/Ausgabefehler

Schritte ich getan habe:

  • Erstellt einen Benutzer namens Transfer
  • Erstellt ein /mnt/backups Verzeichnis und lief chown -R transfer /mnt/backups
  • als Benutzer Übertragung lief gcsfuse --implicit-dir backup01-bucket /mnt/backups. Die Systemdatei besteigt erfolgreich
  • Run mkdir test und den Fehler mkdir: cannot create directory test: Input/output error

Gibt es etwas, was ich verpasst? Ich versuche, Dateien auf den Server zu übertragen und sie im Google-Speicher-Bucket statt im lokalen Speicher zu speichern.

aktualisieren modifizierte ich den Befehl einige Debug-Informationen zu erhalten:

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

Dann mkdir /mnt/backups/test als transfer Benutzer lief.

Die folgenden bedug Informationen herauskommen:

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. 

Hinweis: Wenn ich ein Verzeichnis in der Webkonsole erstelle ich das Verzeichnis in Ordnung zu sehen.

+0

Könnten Sie gcsfuse mit '--foreground' ausführen und Ihre Frage mit der Logging-Ausgabe ändern? Wenn es nichts nützliches gibt, versuchen Sie auch '--debug_gcs' und/oder' --debug_fuse'. – jacobsa

+0

Ich habe die Frage mit Debug-Informationen aktualisiert. Vielen Dank. – user1476207

Antwort

4

Es scheint von den Insufficient Permission Fehlern in Ihrer Debug-Ausgabe, dass gcsfuse nicht über ausreichende Berechtigungen für Ihren Bucket verfügt. Wahrscheinlich hat es nur Lesezugriff.

Lesen Sie unbedingt die credentials Dokumentation für gcsfuse. Insbesondere wenn Sie ein Dienstkonto auf einer GCE-VM verwenden, stellen Sie sicher, dass Sie die VM mit dem Zugriffsbereich storage-full einrichten.

+0

Danke! Leider musste ich die VM neu erstellen, um die API zu aktivieren. Es wurde keine Möglichkeit gefunden, den Speicher so zu ändern, dass er auf einer vorhandenen VM schreibgeschützt ist. – user1476207

+0

Ja, soweit ich weiß, ist es nicht möglich zu ändern. – jacobsa

+0

Gute Neuigkeiten, seit dem 17. Dezember 2016 ist es möglich, die Berechtigungen für eine * gestoppte * VM zu ändern. Siehe https://googlecloudplatform.uservoice.com/forums/302595-compute-engine/suggestions/13101552-ability-to-change-cloud-api-access-scopes-on-launc. Sie können auch die Berechtigungen pro API ändern, beispielsweise weiterhin den Zugriff auf BigQuery verweigern, aber den Speicher voll belegen. – Spotlight

9

Sie Problem stammt aus unzureichenden Berechtigungen, aber Sie müssen nicht müssen die VM mit einem anderen Bereich zu zerstören und neu erstellen, um dieses Problem zu lösen.Hier ist ein weiterer Ansatz, der besser geeignet für Produktionssysteme ist:

  1. Erstellen eines Dienstkontos
  2. Erstellen Sie einen Schlüssel für das Dienstkonto, und laden Sie die JSON-Datei
  3. Grants eine angemessene Rolle für das Dienstkonto
  4. Erteilen Sie die entsprechenden Berechtigungen für das Dienstkonto auf dem Kübel
  5. die JSON-Anmeldeinformationen für das Dienstkonto Laden an die VM
Schließlich

, definieren Sie eine Umgebungsvariable, die den Pfad zu den Dienstkontodaten enthält, wenn gcsfuse von der Kommandozeile aufrufen:

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

Verwenden Sie die Option key_file die gleiche Sache in fstab zu erreichen. Beide Optionen sind in der gcsfuse credentials documentation dokumentiert. (EDIT:. Diese Option ist dokumentiert, aber für mich nicht)

Interessanterweise müssen Sie die Umgebungsvariable oder key_file Option verwenden, auch wenn Sie das Dienstkonto auf dem VM konfiguriert haben:

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

Aus irgendeinem Grund ignoriert gcsfuse das aktive credentials-Konto.

Die Verwendung des Bereichs storage-full beim Erstellen einer VM hat Auswirkungen auf die Sicherheit und Stabilität, da diese VM vollen Zugriff auf alle Buckets haben kann, die zu demselben Projekt gehören. Sollte Ihr Dateispeicherserver wirklich in der Lage sein, die Protokolle in einem Logging-Bucket zu überschreiben oder die Datenbanksicherungen in einem anderen Bucket zu lesen?