ECS: błędy zdalnego we/wy NFS; zmiana właściciela zasobnika dla zasobnika z obsługą FS może spowodować, że aplikacje i/lub użytkownicy nie będą mogli uzyskać dostępu do plików NFS
Summary: Poprzedni właściciel zasobnika nie jest dozwolony ani ograniczony. ObjectControllerException: Metoda aktualizacjiObjectInternal nie jest dozwolona dla poprzedniego właściciela zasobnika ...
This article applies to
This article does not apply to
Symptoms
Zmień wprowadzone przez użytkownika na stronę właściciela zasobnika w interfejsie użytkownika:
Ten problem dotyczy zasobników z obsługą NFS i zmiany właściciela zasobnika przez interfejs użytkownika. Może to spowodować utratę dostępu do zasobnika w systemie plików Linux przez aplikacje lub użytkowników. Nawet jeśli przywrócimy zmianę z powrotem na pierwotnego właściciela, dostęp nie będzie możliwy, co prowadzi do DU.
W tym przykładzie
: właściciel zasobnika został zmieniony na "sham2" przy użyciu interfejsu użytkownika. Ze względu na ograniczenia ECS, nawet po zmianie nazwy właściciela zasobnika z powrotem na "sham1". EcS nie zmieni właściciela zasobnika z powrotem na "sham1" przy użyciu interfejsu użytkownika. Na razie można to zrobić tylko przy użyciu interfejsu CLI przy użyciu interfejsu API z obciążeniem, aby zresetować flagę właściciela do true.
Sposoby identyfikacji problemu: na komputerze z systemem Linux należy poprosić użytkownika o dotknięcie pliku na przykład:
Ten problem dotyczy zasobników z obsługą NFS i zmiany właściciela zasobnika przez interfejs użytkownika. Może to spowodować utratę dostępu do zasobnika w systemie plików Linux przez aplikacje lub użytkowników. Nawet jeśli przywrócimy zmianę z powrotem na pierwotnego właściciela, dostęp nie będzie możliwy, co prowadzi do DU.
W tym przykładzie
: właściciel zasobnika został zmieniony na "sham2" przy użyciu interfejsu użytkownika. Ze względu na ograniczenia ECS, nawet po zmianie nazwy właściciela zasobnika z powrotem na "sham1". EcS nie zmieni właściciela zasobnika z powrotem na "sham1" przy użyciu interfejsu użytkownika. Na razie można to zrobić tylko przy użyciu interfejsu CLI przy użyciu interfejsu API z obciążeniem, aby zresetować flagę właściciela do true.
Sposoby identyfikacji problemu: na komputerze z systemem Linux należy poprosić użytkownika o dotknięcie pliku na przykład:
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
Tworzenie zasobnika z określonym użytkownikiem jako właścicielem, a następnie zmianę właściciela zasobnika. Wreszcie, nadanie pierwotnemu właścicielowi pełnej kontroli przy użyciu strony ACL kończy się niepowodzeniem z wyjątkiem dziennika ECS:
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
Obejście problemu polega na zmianie właściciela zasobnika za pomocą interfejsu API za pośrednictwem interfejsu wiersza poleceń z obciążeniem w celu zresetowania flagi modułu do true.
1. Określ bieżącego właściciela zasobnika.
2. Utwórz prosty plik xml za pomocą edytora VI. W poniższym przykładzie nazwa to /tmp/bucket-owner.xml. Jest to proces dwuetapowy. Musimy tymczasowo ustawić go na nowego właściciela, co jest pozorną2. Jak w poniższym przykładzie, przed przywróceniem pierwotnego właściciela, potwierdź dane wyjściowe:
. 7. Po zakończeniu zmiany konfiguracji nie powinien już pojawiać się ten sam błąd
1. Określ bieżącego właściciela zasobnika.
Wygeneruj TOKEN za pomocą hasła głównego interfejsu użytkownika. Oto przykład:
admin@ecsnode1:~> tok=$(curl -iks https://XX.XX.XX.XX:4443/login -u 'root:ChangeMe' | grep X-SDS-AUTH-TOKEN)
Sprawdź bieżącego właściciela zasobnika (w twojej sytuacji zastępczy pojemnik i przestrzeń nazw):
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>
Potwierdzenie, że parametr reset_previous_owners jest wymagany do ustawienia wartości true. Przywrócony właściciel zasobnika znajduje się w interfejsie użytkownika, ale interfejs API za pośrednictwem interfejsu wiersza poleceń potwierdza, że ECS nadal widzi właściciela zasobnika jako "sham2".
2. Utwórz prosty plik xml za pomocą edytora VI. W poniższym przykładzie nazwa to /tmp/bucket-owner.xml. Jest to proces dwuetapowy. Musimy tymczasowo ustawić go na nowego właściciela, co jest pozorną2. Jak w poniższym przykładzie, przed przywróceniem pierwotnego właściciela, potwierdź dane wyjściowe:
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.
Składnia interfejsu API wymagana do zmiany właściciela zasobnika na "sham2" w pliku xml jest następująca:
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.
Upewnij się, że zmiana właściciela pojemnika jest teraz "pozorna1".
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>
Po przywracaniu właściciela zasobnika w interfejsie API potwierdź, że host może teraz uzyskać dostęp do zasobnika w systemie plików Linux.
. 7. Po zakończeniu zmiany konfiguracji nie powinien już pojawiać się ten sam błąd
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
Powiązane bazy wiedzy NFS:
Możesz zasubskrybować aktualizacje, postępując zgodnie z instrukcjami zawartymi w poniższym artykule bazy wiedzy:
DELL EMC: Jak subskrybować strony produktów — pomoc techniczna firmy Dell?
- ECS: tworzenie podstawowego eksportu NFS i montowanie go w kliencie
- ECS: NFS nie może zapisać lub usunąć obiektów
- ECS: duże zapisy NFS z ESXi mogą zakończyć się niepowodzeniem po aktualizacji 3.2
- ECS: resetowanie konfiguracji eksportu NFS po dodaniu nowego eksportu w środowisku Multi-VDC
- ECS: błąd przesyłania strumieniowego w dzienniku dataheadsvc: łącze procedury NFSv3 nie jest obsługiwane w żądaniu ReadLinkRequest
- ECS: błąd duplikatu plików cookie podczas tworzenia listy NFS
- ECS: niepowodzenie montowania NFS z komunikatem No such file or directory lub ERROR_OBJECT_NOT_FOUND
- ECS: lista plików zasobnika NFS zawierająca ponad 2 miliony plików może działać wolno lub nie działać
- ECS: Podfolder lub katalog utworzony za pomocą przeglądarki S3 nie jest wymieniony przez klienta NFS/maszynę Linux, ale zawartość podfolderu jest wyświetlana w katalogu głównym lub głównym
- ECS: podczas próby zapisania do zasobnika NFS pojawia się błąd zdalnego we/wy
- ECS: Błędy zdalnego we/wy NFS; Zmiana właściciela zasobnika dla zasobnika z obsługą FS może spowodować, że aplikacje/użytkownicy nie będą mogli uzyskać dostępu do plików NFS
- ECS: zapis NFS zgłasza błąd we/wy po określonej ilości danych.
- ECS: korzystanie z udostępniania plików NFS w ECS z magazynem danych VMware NFS
- ECS: najlepsze praktyki dotyczące montowania eksportów ECS NFS
- ECS: montowanie udziału NFS w kliencie Windows
- ECS: nie można zamontować NFS po zmianie ustawień eksportu plików w interfejsie użytkownika
- ECS: czy oprogramowanie Oracle WebCenter Content (WCC) jest zgodne z ECS?
Możesz zasubskrybować aktualizacje, postępując zgodnie z instrukcjami zawartymi w poniższym artykule bazy wiedzy:
DELL EMC: Jak subskrybować strony produktów — pomoc techniczna firmy Dell?