Ошибки удаленного ввода-вывода NFS; Изменение владельца контейнера для контейнера с файловой системой может привести к тому, что приложения и/или пользователи не смогут получить доступ к файлам NFS

Oversigt: Предыдущий владелец контейнера не разрешен или ограничен ObjectControllerException: метод updateObjectInternal не разрешен для предыдущего владельца контейнера

Berørte produkter

Denne artikel gælder for Denne artikel gælder ikke for Denne artikel er ikke knyttet til et bestemt produkt. Det er ikke alle produktversioner, der er identificeret i denne artikel.

Udforsk andre ressourcer

Symptomer

Изменение, внесенное пользователем на странице владельца контейнера в пользовательском интерфейсе:
kA23a0000000BOMCA2_3_0

Эта проблема относится к контейнерам с включенной поддержкой NFS и смене владельца контейнера через пользовательский интерфейс. Это может привести к тому, что приложения или пользователи, подключенные к контейнеру, утратят доступ к контейнеру в файловой системе Linux. Даже если мы снова вернем первоначального владельца изменения, доступ будет невозможен, что приведет к DU.

В этом примере:
владелец контейнера был изменен на «sham2» с помощью пользовательского интерфейса. Из-за ограничения в ECS даже после изменения имени владельца контейнера обратно на «sham1». ECS не изменит владельца контейнера обратно на «sham1» с помощью пользовательского интерфейса. На данный момент это можно сделать только с помощью интерфейса командной строки, использующего API с полезными данными, чтобы сбросить флаг владельца в true.

Способы определения проблемы, на компьютере с Linux попросите пользователя коснуться файла, например:

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

Årsag

Создание контейнера с конкретным пользователем в качестве владельца с последующей сменой владельца контейнера. Наконец, предоставление исходному владельцу полного доступа с помощью страницы списков контроля доступа завершается сбоем с исключением журнала 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.

Løsning

Временное решение заключается в том, чтобы изменить владельца контейнера с помощью API через интерфейс командной строки с полезной нагрузкой, чтобы сбросить флаг владельца в значение true.

1. Определите текущего владельца контейнера.

Для создания TOKEN требуется пароль root пользовательского интерфейса. Пример.

admin@ecsnode1:~> tok=$(curl -iks https://XX.XX.XX.XX:4443/login -u 'root:ChangeMe' | grep X-SDS-AUTH-TOKEN)

Проверьте текущего владельца контейнера (в вашей ситуации замените контейнер и пространство имен):

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>

Это подтверждает, что для reset_previous_owners параметра необходимо установить значение «истина». В пользовательском интерфейсе указан возвращенный владелец контейнера, но API-интерфейс посредством интерфейса командной строки подтверждает, что ECS по-прежнему видит владельца контейнера как «sham2».

2. Создайте простой XML-файл с помощью редактора vi. В приведенном ниже примере он называется /tmp/bucket-owner.xml. Это двухэтапный процесс. Мы должны временно установить его на нового владельца sham2. Как показано в приведенном ниже примере, перед возвратом к первоначальному владельцу 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>sham2</new_owner>
   <reset_previous_owners>true</reset_previous_owners>
</object_bucket_update_owner>

3. Change the bucket owner to the temporary owner.

Синтаксис API, необходимый для изменения владельца контейнера на "sham2" через XML-файл, следующий:

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.

Убедитесь, что смена владельца контейнера теперь «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>

После возврата владельца контейнера в API убедитесь, что хост теперь может получить доступ к контейнеру в файловой системе Linux.

. 7. После изменения конфигурации мы больше не должны видеть ту же ошибку

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.

Flere oplysninger

Связанные статьи базы знаний NFS:

Подпишитесь на обновления продукта.
Вы можете подписаться на обновления, следуя инструкциям в статье базы знаний ниже.DELL
EMC. Как подписаться на страницы продуктов — Dell Support?

Berørte produkter

Elastic Cloud Storage

Produkter

ECS Appliance, ECS Appliance Software with Encryption, ECS Appliance Software without Encryption, Elastic Cloud Storage

Artikelnummer: 000055535

Artikeltype: Solution

Senest ændret: 29 jul. 2026

Version: 5

Kontrollér, om din enhed er dækket af supportservices.

Oversigt: Предыдущий владелец контейнера не разрешен или ограничен ObjectControllerException: метод updateObjectInternal не разрешен для предыдущего владельца контейнера

Symptomer

Årsag

Løsning

Yderligere oplysninger

Berørte produkter

Symptomer

Årsag

Løsning

Flere oplysninger

Berørte produkter

Produkter

Artikelegenskaber

Find svar på dine spørgsmål fra andre Dell-brugere

Supportservices

Artikelegenskaber

Find svar på dine spørgsmål fra andre Dell-brugere

Supportservices

Oversigt: Предыдущий владелец контейнера не разрешен или ограничен ObjectControllerException: метод updateObjectInternal не разрешен для предыдущего владельца контейнера

Detaljeret artikel

Symptomer

Årsag

Løsning

Yderligere oplysninger

Berørte produkter

Symptomer

Årsag

Løsning

Flere oplysninger

Berørte produkter

Produkter

Artikelegenskaber

Find svar på dine spørgsmål fra andre Dell-brugere

Supportservices

Artikelegenskaber

Find svar på dine spørgsmål fra andre Dell-brugere

Supportservices