ECS: NFS Remote I/O-fejl; Skift af bucket-ejer til FS-aktiveret bucket kan føre til programmer og eller brugere, der ikke kan få adgang til NFS-filer
Summary: Forrige bucket-ejer er ikke tilladt eller begrænset ObjectControllerException: MetodeopdateringObjectInternal not allowed for previous bucket owner
This article applies to
This article does not apply to
Symptoms
Ændring foretaget af brugeren til bucket-ejersiden i brugergrænsefladen:
Dette problem gælder for NFS-aktiverede filsæt og en ændring af bucket-ejeren i brugergrænsefladen. Dette kan medføre, at programmer eller brugere, der er tilsluttet, mister adgang til bucket'en på Linux-filsystemet. Selv hvis vi vender tilbage til ændringen til den oprindelige ejer igen, vil det ikke være muligt at få adgang til DU.
I dette eksempel:
Bucket-ejeren blev ændret til "sham2" ved hjælp af brugergrænsefladen. På grund af en begrænsning i ECS, selv efter ændring af bucket-ejernavnet tilbage til "sham1". ECS vil ikke ændre bucket-ejeren tilbage til "sham1" ved hjælp af brugergrænsefladen. Dette kan kun gøres for nu med CLI ved hjælp af en API med nyttedata til at nulstille ejerens flag til sand.
Måder at identificere problemet på Linux-maskinen beder brugeren om at røre ved en fil, f.eks.:
Dette problem gælder for NFS-aktiverede filsæt og en ændring af bucket-ejeren i brugergrænsefladen. Dette kan medføre, at programmer eller brugere, der er tilsluttet, mister adgang til bucket'en på Linux-filsystemet. Selv hvis vi vender tilbage til ændringen til den oprindelige ejer igen, vil det ikke være muligt at få adgang til DU.
I dette eksempel:
Bucket-ejeren blev ændret til "sham2" ved hjælp af brugergrænsefladen. På grund af en begrænsning i ECS, selv efter ændring af bucket-ejernavnet tilbage til "sham1". ECS vil ikke ændre bucket-ejeren tilbage til "sham1" ved hjælp af brugergrænsefladen. Dette kan kun gøres for nu med CLI ved hjælp af en API med nyttedata til at nulstille ejerens flag til sand.
Måder at identificere problemet på Linux-maskinen beder brugeren om at røre ved en fil, f.eks.:
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
Oprettelse af en bucket med en bestemt bruger som ejer efterfulgt af en ændring af ejerskabet af bucket'en. Slut med at give den oprindelige ejer fuld kontrol ved hjælp af siden ACL'er mislykkes med ECS-logundtagelse:
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
Løsningen er at ændre bucket-ejeren ved hjælp af API'en via CLI med nyttedata for at nulstille ejerens flag til sand.
1. Bestem den aktuelle bucket-ejer.
2. Opret en simpel XML-fil ved hjælp af Vi Editor. I eksemplet nedenfor hedder det /tmp/bucket-owner.xml. Dette er en totrinsproces. Vi er nødt til midlertidigt at indstille den til en ny ejer af sham2. Som i dette eksempel nedenfor skal du, før du går tilbage til den oprindelige ejer sham1, bekræfte outputtet:
. 7. Når konfigurationsændringen er udført, bør vi ikke se den samme fejl mere
1. Bestem den aktuelle bucket-ejer.
Kræv brugergrænsefladens rodadgangskode for at generere TOKENet. F.eks.:
admin@ecsnode1:~> tok=$(curl -iks https://XX.XX.XX.XX:4443/login -u 'root:ChangeMe' | grep X-SDS-AUTH-TOKEN)
Kontroller den aktuelle bucket-ejer (erstatningssæt og navneområde i din 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>
Dette bekræfter, at parameter reset_previous_owners skal indstilles til sand. Den tilbageførte bucket-ejer er på brugergrænsefladen, men API'en via CLI bekræfter, at ECS stadig ser bucket-ejeren som "sham2".
2. Opret en simpel XML-fil ved hjælp af Vi Editor. I eksemplet nedenfor hedder det /tmp/bucket-owner.xml. Dette er en totrinsproces. Vi er nødt til midlertidigt at indstille den til en ny ejer af sham2. Som i dette eksempel nedenfor skal du, før du går tilbage til den oprindelige ejer sham1, bekræfte outputtet:
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.
DEN API-syntaks, der kræves for at ændre bucket-ejeren til "sham2" via XML-filen, er som følger:
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.
Bekræft, at ændringen af bucket-ejeren nu er "sham1".
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>
Når bucket-ejeren er gendannet på API'en, skal du bekræfte, at værten nu kan få adgang til bucket'en på Linux-filsystemet.
. 7. Når konfigurationsændringen er udført, bør vi ikke se den samme fejl mere
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
Relateret NFS KB:
Du kan abonnere på opdateringer ved at følge vejledningen i vidensartiklen nedenfor:
DELL EMC: Hvordan abonnerer du på produktsiderne – Dell Support?
- ECS: Sådan opretter du en grundlæggende NFS-eksport og installerer den på en klient
- ECS: NFS kan ikke skrive eller slette objekter
- ECS: Store NFS-skrivninger fra ESXi kan mislykkes efter opgradering til 3.2
- ECS: Nulstilling af NFS-eksportkonfiguration efter tilføjelse af ny eksport i Multi-VDC-miljø
- ECS: Streamingfejl i dataheadsvc-log: NFSv3-procedure-LINK understøttes ikke i anmodning ReadLinkRequest
- ECS: Dupliker cookie-fejl ved registrering af NFS
- ECS: NFS-tilslutning mislykkes uden sådan fil eller mappe eller ERROR_OBJECT_NOT_FOUND
- ECS: Filliste over NFS-buckets, der indeholder mere end 2 millioner filer, kan være langsom eller mislykket
- ECS: Undermappe eller -mappe, der er oprettet ved hjælp af S3-browser, er ikke angivet af NFS Client/Linux-maskinen, men undermappens indhold vises i hoved- eller rodmappen
- ECS: Der blev modtaget fjern-I/O-fejl, når du forsøger at skrive til en bucket med NFS
- ECS: NFS Remote I/O-fejl; Skift af bucket-ejer for FS-aktiveret bucket kan føre til programmer/brugere, der ikke kan få adgang til NFS-filer
- ECS: NFS-skrivninger smider I/O-fejl efter en bestemt mængde data.
- ECS: Brug af NFS-fildeling fra ECS med et VMware NFS-datalager
- ECS: Bedste praksis for montering af ECS NFS-eksport
- ECS: Sådan tilsluttes NFS-deling på Windows-klienten
- ECS: NFS kan ikke tilsluttes efter ændring af fileksportindstillinger i brugergrænsefladen
- ECS: Er Oracle WebCenter-indhold (WCC) kompatibelt med ECS?
Du kan abonnere på opdateringer ved at følge vejledningen i vidensartiklen nedenfor:
DELL EMC: Hvordan abonnerer du på produktsiderne – Dell Support?