ECS: NFS Remote I/O-fouten; Wijziging van bucket-eigenaar voor FS ingeschakelde bucket kan ertoe leiden dat applicaties en/of gebruikers geen toegang hebben tot NFS-bestanden
Summary: Vorige bucketeigenaar is niet toegestaan of beperkt ObjectControllerException: Methode-updateObjectInternal niet toegestaan voor vorige bucketeigenaar
This article applies to
This article does not apply to
Symptoms
De gebruiker wijzigt de bucket-eigenaarspagina in de gebruikersinterface:
Dit probleem is van toepassing op buckets met NFS en een wijziging van de bucket-eigenaar door de gebruikersinterface. Dit kan ertoe leiden dat applicaties of gebruikers die zijn verbonden met verlies van toegang tot de bucket op het Linux-bestandssysteem. Zelfs als we de wijziging terugdraaien naar de oorspronkelijke eigenaar, is toegang niet mogelijk, wat leidt tot DU.
In dit voorbeeld:
De eigenaar van de bucket is gewijzigd in "sham2" met behulp van de gebruikersinterface. Vanwege een beperking in ECS, zelfs nadat u de naam van de bucketeigenaar hebt gewijzigd in "sham1". De ECS verandert de eigenaar van de bucket niet terug naar "sham1" met behulp van de gebruikersinterface. Dit kan voorlopig alleen worden gedaan met de CLI met behulp van een API met payload om de vlag van de eigenaar opnieuw in te stellen op True.
Manieren om het probleem te identificeren, vraag de gebruiker op de Linux-machine om bijvoorbeeld een bestand aan te raken:
Dit probleem is van toepassing op buckets met NFS en een wijziging van de bucket-eigenaar door de gebruikersinterface. Dit kan ertoe leiden dat applicaties of gebruikers die zijn verbonden met verlies van toegang tot de bucket op het Linux-bestandssysteem. Zelfs als we de wijziging terugdraaien naar de oorspronkelijke eigenaar, is toegang niet mogelijk, wat leidt tot DU.
In dit voorbeeld:
De eigenaar van de bucket is gewijzigd in "sham2" met behulp van de gebruikersinterface. Vanwege een beperking in ECS, zelfs nadat u de naam van de bucketeigenaar hebt gewijzigd in "sham1". De ECS verandert de eigenaar van de bucket niet terug naar "sham1" met behulp van de gebruikersinterface. Dit kan voorlopig alleen worden gedaan met de CLI met behulp van een API met payload om de vlag van de eigenaar opnieuw in te stellen op True.
Manieren om het probleem te identificeren, vraag de gebruiker op de Linux-machine om bijvoorbeeld een bestand aan te raken:
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
Een bucket maken met een specifieke gebruiker als eigenaar, gevolgd door een wijziging van het eigendom van de bucket. Tot slot mislukt het geven van de volledige controle van de oorspronkelijke eigenaar met behulp van de ACL-pagina met uitzondering van het ECS-logboek:
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
De tijdelijke oplossing is om de bucket-eigenaar te wijzigen met behulp van de API via CLI met payload om de vlag van de eigenaar opnieuw in te stellen op True.
1. Bepaal de huidige eigenaar van de bucket.
2. Maak een eenvoudig XML-bestand met behulp van de VI-editor. In het onderstaande voorbeeld wordt het /tmp/bucket-owner.xml genoemd. Dit is een proces in twee stappen. We moeten het tijdelijk instellen op een nieuwe eigenaar van sham2. Zoals in dit voorbeeld hieronder, moet u, voordat u de oorspronkelijke eigenaar sham1 terugzet, de uitvoer bevestigen:
. 7. Zodra de configuratiewijziging is voltooid, moeten we niet meer dezelfde fout zien
1. Bepaal de huidige eigenaar van de bucket.
Vereist het rootwachtwoord van de gebruikersinterface om het TOKEN te genereren. Bijvoorbeeld:
admin@ecsnode1:~> tok=$(curl -iks https://XX.XX.XX.XX:4443/login -u 'root:ChangeMe' | grep X-SDS-AUTH-TOKEN)
Controleer de huidige eigenaar van de bucket (vervang bucket en namespace in uw situatie):
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>
Dit bevestigt dat parameter reset_previous_owners moet worden ingesteld op True. De eigenaar van de teruggedraaide bucket bevindt zich op de gebruikersinterface, maar de API via CLI bevestigt dat de ECS de bucket-eigenaar nog steeds ziet als 'sham2'.
2. Maak een eenvoudig XML-bestand met behulp van de VI-editor. In het onderstaande voorbeeld wordt het /tmp/bucket-owner.xml genoemd. Dit is een proces in twee stappen. We moeten het tijdelijk instellen op een nieuwe eigenaar van sham2. Zoals in dit voorbeeld hieronder, moet u, voordat u de oorspronkelijke eigenaar sham1 terugzet, de uitvoer bevestigen:
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.
De API-syntaxis die nodig is om de bucket-eigenaar te wijzigen in "sham2" via het xml-bestand is als volgt:
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.
Bevestig dat de wijziging van de bucket-eigenaar nu "sham1" is.
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>
Nadat de eigenaar van de bucket is teruggezet op de API, bevestigt u dat de host nu toegang heeft tot de bucket op het Linux-bestandssysteem.
. 7. Zodra de configuratiewijziging is voltooid, moeten we niet meer dezelfde fout zien
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
Gerelateerde NFS KB:
U kunt zich abonneren op updates door de instructies in het onderstaande Knowledge-artikel te volgen:
DELL EMC: Hoe kan ik u abonneren op productpagina's - Dell Support?
- ECS: Een basis NFS-export maken en koppelen op een client
- ECS: NFS kan geen objecten schrijven of verwijderen
- ECS: Grote NFS-schrijfbewerkingen vanaf ESXi kunnen mislukken na een upgrade van 3.2
- ECS: NFS-exportconfiguratie opnieuw instellen na toevoegen van nieuwe export in multi-VDC-omgeving
- ECS: fout bij het streamen van dataheadsvc-logboeken: LINK NFSv3-procedure niet ondersteund in aanvraag ReadLinkRequest
- ECS: Dubbele cookiefout bij het weergeven van NFS
- ECS: NFS-koppeling mislukt zonder een dergelijk bestand of map of ERROR_OBJECT_NOT_FOUND
- ECS: Bestandslijst van NFS-bucket met meer dan 2 miljoen bestanden kan traag of mislukt zijn
- ECS: Submap of map die is gemaakt met de S3-browser wordt niet vermeld door de NFS Client/Linux-machine, maar de inhoud van de submap wordt weergegeven in de hoofd- of hoofdmap
- ECS: Externe I/O-fout ontvangen bij een poging om naar een bucket met NFS te schrijven
- ECS: NFS Remote I/O-fouten; Wijziging van bucket-eigenaar voor FS ingeschakelde bucket kan ertoe leiden dat applicaties/gebruikers geen toegang hebben tot NFS-bestanden
- ECS: NFS write genereert een I/O-fout na een bepaalde hoeveelheid data.
- ECS: NFS-bestandsshare van ECS gebruiken met een VMware NFS-datastore
- ECS: Aanbevolen werkwijzen voor het koppelen van ECS NFS-exports
- ECS: NFS-share koppelen op Windows-client
- ECS: NFS kan niet worden gekoppeld na wijziging van bestandsexportinstellingen in de gebruikersinterface
- ECS: Is Oracle WebCenter Content (WCC) compatibel met ECS?
U kunt zich abonneren op updates door de instructies in het onderstaande Knowledge-artikel te volgen:
DELL EMC: Hoe kan ik u abonneren op productpagina's - Dell Support?