ECS: NFS-Remote-I/O-Fehler. Die Änderung des Bucket-Eigentümers für FS-kompatiblen Bucket kann dazu führen, dass Anwendungen und/oder NutzerInnen nicht auf NFS-Dateien zugreifen können.
Summary: Vorheriger Bucket-Eigentümer ist nicht zulässig oder eingeschränkte ObjectControllerException: Method updateObjectInternal ist für den vorherigen Bucket-Eigentümer nicht zulässig
This article applies to
This article does not apply to
Symptoms
Änderung, die vom Benutzer auf der Bucket-Eigentümerseite auf der Benutzeroberfläche vorgenommen wird:
Dieses Problem gilt für NFS-fähige Buckets und eine Änderung des Bucket-Eigentümers durch die Benutzeroberfläche. Dies kann dazu führen, dass Anwendungen oder Benutzer, die verbunden sind, den Zugriff auf den Bucket auf dem Linux-Dateisystem verloren haben. Selbst wenn wir die Änderung wieder auf den ursprünglichen Eigentümer zurücksetzen, ist ein erneuter Zugriff nicht möglich, was zu einer Nichtverfügbarkeit von Daten führt.
In diesem Beispiel:
Der Bucket-Eigentümer wurde über die Benutzeroberfläche in "sham2" geändert. Aufgrund einer Einschränkung in ECS, auch nachdem der Bucket-Eigentümername wieder in "sham1" geändert wurde. EcS ändert den Bucket-Eigentümer nicht über die Benutzeroberfläche zurück zu "sham1". Dies kann derzeit nur mit der CLI mithilfe einer API mit Nutzlast erfolgen, um das Flag des Owners auf "true" zurückzusetzen.
Möglichkeiten zur Identifizierung des Problems: Bitten Sie den Benutzer auf dem Linux-Rechner, eine Datei zu berühren, z. B.:
Dieses Problem gilt für NFS-fähige Buckets und eine Änderung des Bucket-Eigentümers durch die Benutzeroberfläche. Dies kann dazu führen, dass Anwendungen oder Benutzer, die verbunden sind, den Zugriff auf den Bucket auf dem Linux-Dateisystem verloren haben. Selbst wenn wir die Änderung wieder auf den ursprünglichen Eigentümer zurücksetzen, ist ein erneuter Zugriff nicht möglich, was zu einer Nichtverfügbarkeit von Daten führt.
In diesem Beispiel:
Der Bucket-Eigentümer wurde über die Benutzeroberfläche in "sham2" geändert. Aufgrund einer Einschränkung in ECS, auch nachdem der Bucket-Eigentümername wieder in "sham1" geändert wurde. EcS ändert den Bucket-Eigentümer nicht über die Benutzeroberfläche zurück zu "sham1". Dies kann derzeit nur mit der CLI mithilfe einer API mit Nutzlast erfolgen, um das Flag des Owners auf "true" zurückzusetzen.
Möglichkeiten zur Identifizierung des Problems: Bitten Sie den Benutzer auf dem Linux-Rechner, eine Datei zu berühren, z. B.:
admin@node1~>touch file
touch: setting times of `file': Remote I/O error
se svc_log with the string "method updateObjectInternal "
Command:
# svc_log -a -sr dataheadsvc | grep "method updateObjectInternal"
Example:
admin@node1~>svc_log -a -sr dataheadsvc | grep "method updateObjectInternal" svc_log v1.0.22 (svc_tools v1.5.3) Started 2019-06-06 10:45:04 Running on nodes: <All nodes> Time range: 2019-06-05 10:45:04 - 2019-06-06 10:45:04 Filter string(s): <All messages> Show nodename(s): True Search reclaim logs (if any): False com.emc.storageos.data.object.exception.ObjectControllerException: method updateObjectInternal not allowed for previous bucket owner sham1 Caused by: com.emc.storageos.data.object.exception.ObjectControllerException: method updateObjectInternal not allowed for previous bucket owner sham1
Cause
Erstellen eines Buckets mit einem bestimmten Benutzer als Eigentümer, gefolgt von einer Änderung der Eigentumsrechte für den Bucket. Schließlich schlägt die vollständige Kontrolle des ursprünglichen Eigentümers mithilfe der ACLs-Seite mit der ECS-Protokollausnahmeregelung fehl:
ObjectControllerException: method updateObjectInternal not allowed for previous bucket owner <ownerid> This is a known issue currently being evaluated by Dell EMC at this time.
Resolution
Der Workaround besteht darin, den Bucket-Eigentümer mithilfe der API über die CLI mit Payload zu ändern, um das Flag des Eigentümers auf true zurückzusetzen.
1. Bestimmen Sie den aktuellen Bucket-Eigentümer.
2. Erstellen Sie eine einfache XML-Datei mithilfe des VI-Editors. Im folgenden Beispiel heißt es /tmp/bucket-owner.xml. Dies ist ein zweistufiger Prozess. Wir müssen es vorübergehend auf einen neuen Eigentümer von Sham2 festlegen. Wie in diesem Beispiel unten, bestätigen Sie vor dem Zurücksetzen auf den ursprünglichen Eigentümer sham1 die Ausgabe:
. 7. Sobald die Konfigurationsänderung abgeschlossen ist, sollte derselbe Fehler nicht mehr auftreten.
1. Bestimmen Sie den aktuellen Bucket-Eigentümer.
Fordern Sie das Root-Passwort der Benutzeroberfläche an, um das TOKEN zu erzeugen. Zum Beispiel:
admin@ecsnode1:~> tok=$(curl -iks https://XX.XX.XX.XX:4443/login -u 'root:ChangeMe' | grep X-SDS-AUTH-TOKEN)
Überprüfen Sie den aktuellen Bucket-Eigentümer (ersetzen Sie bucket und namespace in Ihrer Situation):
admin@node1:~> curl -s -k -X GET -H "$tok" https://XX.XX.XX.XX:4443/object/bucket/sham_bk_nfs/info?namespace=degreat_nfs | xmllint --format - | grep '<owner>' <owner>sham2</owner>
Dadurch wird bestätigt, dass der Parameter reset_previous_owners auf "true" festgelegt werden muss. Der zurückgesetzte Bucket-Eigentümer befindet sich auf der Benutzeroberfläche, aber die API über die CLI bestätigt, dass ECS den Bucket-Eigentümer immer noch als "sham2" sieht.
2. Erstellen Sie eine einfache XML-Datei mithilfe des VI-Editors. Im folgenden Beispiel heißt es /tmp/bucket-owner.xml. Dies ist ein zweistufiger Prozess. Wir müssen es vorübergehend auf einen neuen Eigentümer von Sham2 festlegen. Wie in diesem Beispiel unten, bestätigen Sie vor dem Zurücksetzen auf den ursprünglichen Eigentümer sham1 die Ausgabe:
admin@node1:~ # vi /tmp/bucket-owner.xml admin@ecsnode1:~ # cat /tmp/bucket-owner.xml <object_bucket_update_owner> <namespace>degreat_nfs</namespace> <new_owner>sham2</new_owner> <reset_previous_owners>true</reset_previous_owners> </object_bucket_update_owner> 3. Change the bucket owner to the temporary owner.
Die API-Syntax, die erforderlich ist, um den Bucket-Eigentümer über die XML-Datei in "sham2" zu ändern, lautet wie folgt:
admin@ecsnode1:~> curl -v -k -X "POST" "https://xx.xx.xx.xx:4443/object/bucket/sham_bk_nfs/owner" -H "$tok" -H "Content-Type: application/xml" -H "ACCEPT:application/xml" -d @/tmp/bucket-owner.xml -v * Hostname was NOT found in DNS cache * Trying xx.xx.xx.xx... * Connected to xx.xx.xx.xx (xx.xx.xx.xx) port 4443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs/ * SSLv3, TLS unknown, Certificate Status (22): * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, Certificate (11): * SSLv3, TLS handshake, Server key exchange (12): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * Server certificate: * subject: CN=localhost * start date: 2019-03-25 09:53:41 GMT * expire date: 2029-03-22 09:53:41 GMT * issuer: CN=localhost * SSL certificate verify result: self signed certificate (18), continuing anyway. > POST /object/bucket/sham_bk_nfs/owner HTTP/1.1 > User-Agent: curl/7.37.0 > Host: xx.xx.xx.xx:4443 > X-SDS-AUTH-TOKEN: BAAcUy9KYlhxTlVYb2M0bnF3bTNscEsvSEdDeWhJPQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1NTk3Mzk3OTA2MDgDAC51cm46VG9rZW46YjQ4NGNiZjEtNTkwNy00YWI3LTgzYTctM2Y3OGRhM2RiY2NiAgAC0A8= > Content-Type: application/xml > ACCEPT:application/xml > Content-Length: 179 > * upload completely sent off: 179 out of 179 bytes < HTTP/1.1 200 OK < Date: Thu, 06 Jun 2019 10:56:08 GMT < Content-Length: 0 < Connection: keep-alive < * Connection #0 to host xx.xx.xx.xx left intact 4. Edit the simple.xml file previously created in step 2 and this time insert original owner of sham1
admin@node1:~ # vi /tmp/bucket-owner.xml admin@ecsnode1:~ # cat /tmp/bucket-owner.xml <object_bucket_update_owner> <namespace>degreat_nfs</namespace> <new_owner>sham1</new_owner> <reset_previous_owners>true</reset_previous_owners> </object_bucket_update_owner> 5. Change the bucket owner back to the original owner The API syntax required to change the bucket owner back to "sham1" through the xml file is as follows:
admin@ecsnode1:~> curl -v -k -X "POST" "https://xx.xx.xx.xx:4443/object/bucket/sham_bk_nfs/owner" -H "$tok" -H "Content-Type: application/xml" -H "ACCEPT:application/xml" -d @/tmp/bucket-owner.xml -v * Hostname was NOT found in DNS cache * Trying xx.xx.xx.xx... * Connected to xx.xx.xx.xx (xx.xx.xx.xx) port 4443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs/ * SSLv3, TLS unknown, Certificate Status (22): * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, Certificate (11): * SSLv3, TLS handshake, Server key exchange (12): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * Server certificate: * subject: CN=localhost * start date: 2019-03-25 09:53:41 GMT * expire date: 2029-03-22 09:53:41 GMT * issuer: CN=localhost * SSL certificate verify result: self signed certificate (18), continuing anyway. > POST /object/bucket/sham_bk_nfs/owner HTTP/1.1 > User-Agent: curl/7.37.0 > Host: xx.xx.xx.xx:4443 > X-SDS-AUTH-TOKEN: BAAcUy9KYlhxTlVYb2M0bnF3bTNscEsvSEdDeWhJPQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1NTk3Mzk3OTA2MDgDAC51cm46VG9rZW46YjQ4NGNiZjEtNTkwNy00YWI3LTgzYTctM2Y3OGRhM2RiY2NiAgAC0A8= > Content-Type: application/xml > ACCEPT:application/xml > Content-Length: 179 > * upload completely sent off: 179 out of 179 bytes < HTTP/1.1 200 OK < Date: Thu, 06 Jun 2019 10:56:08 GMT < Content-Length: 0 < Connection: keep-alive < * Connection #0 to host xx.xx.xx.xx left intact 6. Confirm the bucket owner change is reflected.
Bestätigen Sie, dass die Änderung des Bucket-Eigentümers jetzt "sham1" ist.
admin@ecsnode1:~> curl -s -k -X GET -H "$tok" https://XX.XX.XX.XX:4443/object/bucket/sham_bk_nfs/info?namespace=degreat_nfs | xmllint --format - | grep '<owner>' <owner>sham1</owner>
Sobald der Bucket-Eigentümer auf der API zurückgesetzt wurde, vergewissern Sie sich, dass der Host jetzt auf den Bucket auf dem Linux-Dateisystem zugreifen kann.
. 7. Sobald die Konfigurationsänderung abgeschlossen ist, sollte derselbe Fehler nicht mehr auftreten.
svc_log -f "method updateObjectInternal not allowed" -start "20 hour ago" -sr all -sh -st hour svc_log v1.0.22 (svc_tools v1.6.8) Started 2020-01-23 09:28:17 Running on nodes: <All nodes> Time range: 2020-01-22 13:28:17 - 2020-01-23 09:28:17 Filter string(s): 'method updateObjectInternal not allowed' Show nodename(s): True Search reclaim logs (if any): False Count of message occurrences per hour: 2020-01-22 13:xx - 5066 2020-01-22 14:xx - 9580 2020-01-22 15:xx - 9574 2020-01-22 16:xx - 9580 2020-01-22 17:xx - 9570 2020-01-22 18:xx - 9576 2020-01-22 19:xx - 9564 2020-01-22 20:xx - 9576 2020-01-22 21:xx - 9576 2020-01-22 22:xx - 9572 2020-01-22 23:xx - 9564 2020-01-23 00:xx - 9586 2020-01-23 01:xx - 9574 2020-01-23 02:xx - 9572 2020-01-23 03:xx - 4564 2020-01-23 04:xx - 0 2020-01-23 05:xx - 0 2020-01-23 06:xx - 0 2020-01-23 07:xx - 0 2020-01-23 08:xx - 0 2020-01-23 09:xx - 0 Dell EMC is aware of this issue and are working on a fix in a future release.
Additional Information
Zugehöriger NFS-Wissensdatenbank-Artikel:
Sie können Updates abonnieren, indem Sie die Anweisungen im folgenden Wissensdatenbank-Artikel befolgen:
DELL EMC: Abonnieren von Produktseiten – Dell Support
- ECS: Anleitung zum Erstellen eines einfachen NFS-Exports und Hinzufügen zu einem Client
- ECS: NFS kann keine Objekte schreiben oder löschen.
- ECS: Große NFS-Schreibvorgänge von ESXi schlagen nach dem 3.2 Upgrade möglicherweise fehl.
- ECS: Zurücksetzen der NFS-Exportkonfiguration nach dem Hinzufügen eines neuen Exports in Multi-VDC-Umgebung
- ECS: Fehler beim dataheadsvc-Protokoll-Streaming: LINK zum NFSv3-Verfahren wird in der Anforderung „ReadLinkRequest“ nicht unterstützt.
- ECS: Fehler wegen doppelten Cookies beim Auflisten von NFS
- ECS: NFS-Mount schlägt fehl mit der Meldung „Datei oder Verzeichnis dieser Art nicht gefunden“ oder „FEHLER – OBJEKT NICHT GEFUNDEN“
- ECS: Dateiauflistung von NFS-Buckets mit mehr als 2 Millionen Dateien kann langsam sein oder fehlschlagen.
- ECS: Unterordner oder Verzeichnis, die mit dem S3-Browser erstellt wurden, werden nicht vom NFS-Client/Linux-Rechner aufgelistet, aber der Inhalt des Unterordners wird im Haupt- oder Stammverzeichnis angezeigt.
- ECS: Remote-I/O-Fehler beim Versuch, in einen Bucket mit NFS zu schreiben
- ECS: NFS-Remote-I/O-Fehler Die Änderung des Bucket-Eigentümers für fs-aktivierten Bucket kann dazu führen, dass Anwendungen/Benutzer nicht auf NFS-Dateien zugreifen können.
- ECS: NFS-Schreibvorgänge geben nach einer bestimmten Datenmenge einen I/O-Fehler aus.
- ECS: Verwenden der NFS-Dateifreigabe von ECS mit einem VMware-NFS-Datenspeicher
- ECS: Best Practices für das Mounten von ECS-NFS-Exporten
- ECS: Anleitung zum Mounten der NFS-Freigabe auf den Windows-Client
- ECS: NFS kann nach dem Ändern der Dateiexporteinstellungen in der Benutzeroberfläche nicht gemountet werden.
- ECS: Ist Oracle WebCenter Content (WCC) mit ECS kompatibel?
Sie können Updates abonnieren, indem Sie die Anweisungen im folgenden Wissensdatenbank-Artikel befolgen:
DELL EMC: Abonnieren von Produktseiten – Dell Support