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

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

Produse afectate

Acest articol se aplică pentru Acest articol nu se aplică pentru Acest articol nu este legat de un produs specific. Acest articol nu acoperă toate versiunile de produs existente.

Consultați alte resurse

Symptoms

Изменение, внесенное пользователем на странице владельца контейнера в пользовательском интерфейсе:
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

Cause

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

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

Additional Information

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

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

Produse afectate

Elastic Cloud Storage

Produse

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

Article Number: 000055535

Article Type: Solution

Ultima modificare: 29 iul. 2026

Version: 5

Verificați dacă dispozitivul dvs. este acoperit de serviciile de asistență.

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

Symptoms

Cause

Resolution

Informații suplimentare

Produse afectate

Symptoms

Cause

Resolution

Additional Information

Produse afectate

Produse

Proprietăți articol

Găsiți răspunsuri la întrebările dvs. de la alți utilizatori Dell

Servicii de asistență

Proprietăți articol

Găsiți răspunsuri la întrebările dvs. de la alți utilizatori Dell

Servicii de asistență

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

Articol detaliat

Symptoms

Cause

Resolution

Informații suplimentare

Produse afectate

Symptoms

Cause

Resolution

Additional Information

Produse afectate

Produse

Proprietăți articol

Găsiți răspunsuri la întrebările dvs. de la alți utilizatori Dell

Servicii de asistență

Proprietăți articol

Găsiți răspunsuri la întrebările dvs. de la alți utilizatori Dell

Servicii de asistență