久久av每日更新免费观看,午夜福利h肉动漫在线观看,91亚洲中文天堂在线观看

OSS數據卷是通過ossfs文件進行掛載的FUSE文件系統。您可以通過分析Debug日志或查詢Pod日志的方式進行ossfs異常問題的排查。本文劃分了常見的ossfs異常問題，并通過示例介紹了兩種運行方式的ossfs通用的排查方法。

排查說明

CSI存儲插件為v1.26.6之前的版本中，ossfs以后臺形式運行在業務Pod所在的節點上，運行異常時需要重新以前臺方式掛載，您可以通過分析Debug日志進行排查。
CSI存儲插件為v1.26.6及之后的版本中，ossfs以容器形式運行在kube-system命名空間下的Pod中，您可以直接查詢Pod的日志進行排查。
CSI存儲插件為v1.30.4及之后的版本中，ossfs以容器形式運行在ack-csi-fuse命名空間下的Pod中，您可以直接查詢Pod的日志進行排查。
重要
為避免ossfs運行時產生大量日志，以容器方式運行時默認的日志等級為critical或error。在進行Debug排查時，可能需要增加Debug參數并重新掛載。

適用場景1：掛載失敗

OSS靜態卷掛載失敗，Pod無法啟動，Event提示FailedMount時，請優先參見OSS存儲卷掛載失敗進行快速排查。

CSI Plugin組件為1.26.6之前的版本

問題現象

業務Pod啟動時，長期處于ContainerCreating狀態。

問題原因

執行以下命令，查詢Pod無法正常啟動的原因。
需替換的變量如下：
- <POD_NAMESPACE>：業務Pod所在的命名空間。
- <POD_NAME>：業務Pod名稱。
```
kubectl -n <POD_NAMESPACE> describe pod <POD_NAME>
```
查詢結果的Events中是否存在原因為FailedMount的事件。
需替換的變量如下：
- <PV_NAME>：OSS存儲卷名稱。
- <BUCKET>：掛載的OSS Bucket名稱。
- <PATH>：掛載的OSS Bucket的路徑。
- <POD_UID>：業務Pod的UID。
```
Warning  FailedMount  3s  kubelet  MountVolume.SetUp failed for volume "<PV_NAME>" : rpc error: code = Unknown desc = Mount is failed in host, mntCmd:systemd-run --scope -- /usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other , err: ..... with error: exit status 1
```
  出現此類事件的原因：CSI組件在拉起ossfs時，ossfs異常退出，此時節點上無對應的ossfs進程在運行。OSS連通性檢查出錯（Bucket不存在，權限配置錯誤等）、掛載路徑不存在、無讀寫權限等初始化檢查的錯誤都可能導致此錯誤現象。

解決方案

步驟1：獲取原ossfs啟動指令

通過查詢FailedMount事件，查看掛載異常的輸出。具體操作，請參見適用場景1：掛載失敗中的場景1。

通過掛載異常的輸出獲取原ossfs啟動指令。

掛載異常輸出示例如下：

Warning  FailedMount  3s  kubelet  MountVolume.SetUp failed for volume "<PV_NAME>" : rpc error: code = Unknown desc = Mount is failed in host, mntCmd:systemd-run --scope -- /usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other , err: ..... with error: exit status 1

其中，在mntCmd中，system-run --scope -- 后端內容為原ossfs的啟動指令。獲取到原ossfs啟動指令如下：

/usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

步驟2：前臺掛載ossfs并獲取Debug日志

ossfs掛載的目錄訪問權限默認為掛載點的所有者，即執行掛載命令的用戶，其他用戶無法訪問。因此若原指令中沒有-o allow_other配置項，可能導致掛載根路徑的權限問題。

確認是否為掛載點路徑權限問題。
如果權限存在問題，請直接在創建PV時，增加配置項-o allow_other。關于ossfs的掛載點目錄訪問權限配置，請參見配置訪問權限，關于如何增加配置項，請參見使用OSS靜態存儲卷。

執行以下命令，在業務Pod所在節點以前臺方式運行ossfs，并設置日志為Debug模式。

其中，/test為測試用的掛載點路徑，前臺運行的ossfs將把OSS Bucket掛載到/test中。

mkdir /test && /usr/local/bin/ossfs <BUCKET>:/<PATH> /test -ourl=oss-cn-beijing-internal.aliyuncs.com -f -o allow_other -o dbglevel=debug -o curldbg

參數	說明
-f	以前臺方式而非守護進程方式運行ossfs，在前臺模式下，日志會輸出到終端屏幕。該參數一般用于調試問題時使用。
-o allow_other	賦予計算機上其他用戶訪問掛載目錄的權限，避免前臺掛載ossfs時，出現新的掛載點路徑權限問題。
-o dbglevel=debug	設置ossfs的日志等級為debug。
-o curldbg	打開libcurl的日志信息，用于排查OSS服務端返回的錯誤。

步驟3：分析Debug日志

以前臺方式運行ossfs后，日志將輸出到終端。通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯，以及ossfs向OSS服務端發送請求后收到非200錯誤碼。下文分別以兩種拋錯類型的例子介紹通用的排查方法。

下文以掛載失敗場景中，ossfs運行后很快退出為例介紹如何進行問題排查。

ossfs自身拋錯

查詢日志，發現ossfs退出前打印的錯誤日志如下。

ossfs: MOUNTPOINT directory /test is not empty. if you are sure this is safe, can use the 'nonempty' mount option.

根據日志信息定位，報錯的原因是掛載點路徑本為非空，可通過增加配置項-o nonempty解決。

說明

根據錯誤日志，可在OSS文檔ossfs常見問題查詢相關解決方法。若未找到相關原因，請提交工單解決。

OSS服務端返回非200錯誤碼

查詢日志，發現ossfs退出前打印的OSS服務端的返回碼為404，錯誤原因為NoSuchBucket，錯誤信息為The specified bucket does not exist。

[INFO]       Jul 10 2023:13:03:47:/tmp/ossfs/src/curl.cpp:RequestPerform(2382): HTTP response code 404 was returned, returning ENOENT, Body Text: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist.</Message>
  <RequestId>xxxx</RequestId>
  <HostId><BUCKET>.oss-cn-beijing-internal.aliyuncs.com</HostId>
  <BucketName><BUCKET></BucketName>
  <EC>0015-00000101</EC>
</Error>

通過日志信息定位，報錯的原因為掛載的OSS Bucket不存在，可通過登錄OSS管理控制臺創建Bucket后重新掛載解決。

說明

通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。

CSI Plugin組件為1.26.6及之后的版本

問題現象

業務Pod啟動時，長期處于ContainerCreating狀態。

問題原因

執行以下命令，確認ossfs容器是否正常運行。
替換以下<PV_NAME>為實際業務PV的名稱。
CSI版本小于1.30.4時，執行：
```
kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<PV_NAME>
```
- 若ossfs容器運行異常，則預期輸出為：
```
NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    0/1     CrashLoopBackOff   1 (4s ago)   5s
```
- 若ossfs容器運行正常，請排查是否由于節點異常等原因導致Pod處于ContainerCreating狀態。
CSI版本大于等于1.30.4時，執行：
```
kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<PV_NAME>
```
- 由于該版本ossfs容器中新增守護進程，無論ossfs進程是否正常運行，預期輸出均為：
```
NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    1/1     Running            0            5s
```
  若ossfs容器處于非Running狀態，請先排查異常原因。

出現此類事件的原因：CSI組件在拉起ossfs容器時，ossfs異常退出。OSS連通性檢查出錯（例如Bucket不存在和權限配置錯誤等）、OSS掛載路徑不存在、無讀寫權限等初始化檢查的錯誤均可能導致此問題。

解決方案

執行以下命令，查詢ossfs容器日志。
CSI版本小于1.30.4時，執行：
```
kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx 
```
CSI版本大于等于1.30.4時，執行：
```
kubectl -n ack-csi-fuse logs -p csi-fuse-ossfs-xxxx 
```
（可選）如果日志為空，或信息過少無法定位問題，說明日志等級過高，需要通過以下方式增加相關配置。
說明
該方式無需重新部署新的Debug存儲卷及對應的存儲聲明，但無法直獲取OSS側的rest請求響應。
1. 創建用于Debug的OSS存儲卷，在原存儲卷配置的基礎上，在otherOpts字段中增加-o dbglevel=debug -o curldbg。使用新建的OSS存儲卷掛載后，通過kubectl logs指令從ossfs Pod獲取Debug日志。Debug日志量較大，僅建議在Debug場景使用。
2. 使用以下內容，在kube-system空間創建名為csi-plugin的ConfiMap。將日志等級設為debug。
  說明
  CSI plugin 1.28.2及之前的版本，日志等級只能設置到info。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: csi-plugin
  namespace: kube-system
data:
  fuse-ossfs: |
    dbglevel=debug # 日志  level
```
  重啟應用所在節點的csi-plugin Pod及csi-provisioner的所有Pod，使Configmap的配置生效，重啟應用Pod觸發重掛載，并確認重掛載后的csi-fuse-ossfs-xxxx重新部署。
  重要
  ConfigMap為全局配置，Debug完成后，請刪除該ConfigMap，再次重啟節點的csi-plugin Pod及csi-provisioner的所有Pod以關閉Debug日志。最后重啟應用Pod再次觸發重掛載，避免ossfs產生大量Debug日志。
分析ossfs容器日志。
通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯和ossfs向OSS服務端發送請求后收到非200錯誤碼。以下通過兩種拋錯類型的示例介紹通用的排查方法。
ossfs自身拋錯
查詢日志，發現ossfs退出前打印的錯誤日志如下。
```
ossfs: MOUNTPOINT directory /test is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
```
根據日志信息定位，報錯的原因是掛載點路徑本應為非空，可通過增加配置項-o nonempty解決。
說明
根據錯誤日志，可在OSS文檔ossfs常見問題查詢相關解決方法。若未找到相關原因，請提交工單解決。
OSS服務端返回非200錯誤碼
查詢日志，發現ossfs退出前檢查掛載Bucket時，OSS服務端返回的錯誤碼為404，錯誤原因為NoSuchBucket，錯誤信息為The specified bucket does not exist。
```
[ERROR]  2023-10-16 12:38:38:/tmp/ossfs/src/curl.cpp:CheckBucket(3420): Check bucket failed, oss response: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist.</Message>
  <RequestId>652D2ECEE1159C3732F6E0EF</RequestId>
  <HostId><bucket-name>.oss-<region-id>-internal.aliyuncs.com</HostId>
  <BucketName><bucket-name></BucketName>
  <EC>0015-00000101</EC>
  <RecommendDoc>https://api.aliyun.com/troubleshoot?q=0015-00000101</RecommendDoc>
</Error>
```
通過日志信息定位，報錯的原因為掛載的OSS Bucket不存在，可通過登錄OSS管理控制臺創建Bucket后重新掛載解決。
說明
通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。
其他說明
- 如果您的日志等級過高，無法定位問題，并且包含以下需求：
  - 不希望重建OSS存儲卷。
  - 擔心全局ConfigMap配置影響其他問題，例如，Debug期間可能發生的其他OSS存儲卷的掛載或卸載。
  此時，您可以以前臺方式掛載ossfs并獲取Debug日志進行定位。具體操作，請參見CSI Plugin組件為1.26.6之前的版本問題的處理。
  重要
  ossfs容器化運行后，節點未默認安裝ossfs。手動安裝的ossfs版本與實際Pod中運行的ossfs版本可能不一致，建議您優先參考上述解決方案，通過變更PV掛載參數或全局ConfigMap配置的方式進行排查。
- 執行以下操作掛載ossfs：
  1. 安裝最新版本的ossfs。安裝方法，請參見安裝ossfs。
  2. 在節點上執行以下操作，獲取PV名稱的sha256值：
```
echo -n "<pv-name>" | sha256sum
```
    如對"pv-oss"，預期輸出為：
```
8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928
```
  3. 在節點上執行以下操作，獲取ossfs的掛載參數：
```
ps -aux | grep <sha256-value>
```
    預期輸出中包含ossfs的進程記錄。
  4. 在節點上執行以下命令，生成ossfs掛載時需要的鑒權信息。在Debug之后，請您及時清理該文件。
```
mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs
```

適用場景2：執行POSIX指令拋錯

CSI Plugin組件為1.26.6之前的版本

問題現象

業務Pod狀態為Running，但執行讀寫等POSIX指令時ossfs拋錯。

問題原因

借助業務的日志確認發生錯誤的指令及返回的錯誤類型。例如，執行chmod -R 777 /mnt/path指令時返回I/O error。

執行以下命令，進入業務Pod確認。

kubectl -n <POD_NAMESPACE> exec -it <POD_NAME> -- /bin/bash

bash-4.4# chmod -R 777 /mnt/path
chmod: /mnt/path: I/O error

出現此類事件的原因：CSI組件在拉起ossfs后，ossfs進程正常運行，并在業務Pod所在節點指定的掛載點路徑掛載OSS Bucket。但在執行chmod、read、open等POSIX指令時，ossfs運行異常并返回錯誤。

解決方案

步驟1：獲取原ossfs啟動指令

由于ossfs已在節點上運行，您可以通過OSS存儲卷名稱在業務Pod所在的節點上執行以下指令，獲取原ossfs啟動指令。

ps -aux | grep ossfs | grep <PV_NAME>

預期輸出：

root     2097450  0.0  0.2 124268 33900 ?        Ssl  20:47   0:00 /usr/local/bin/ossfs <BUCKET> /<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

將預期輸出中<BUCKET>后面的空格替換為冒號（:），即由<BUCKET> /<PATH>改為<BUCKET>:/<PATH>，獲取到原ossfs啟動指令如下。

/usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

步驟2：前臺掛載ossfs并獲取Debug日志

確認是否為掛載點路徑權限問題。
如果權限存在問題，請直接在創建PV時，增加配置項-o allow_other。關于ossfs的掛載點目錄訪問權限配置，請參見配置訪問權限，關于如何增加配置項，請參見使用OSS靜態存儲卷。

執行以下命令，在業務Pod所在節點以前臺方式運行ossfs，并設置日志為Debug模式。

其中，/test為測試用的掛載點路徑，前臺運行的ossfs將把OSS Bucket掛載到/test中。

mkdir /test && /usr/local/bin/ossfs <BUCKET>:/<PATH> /test -ourl=oss-cn-beijing-internal.aliyuncs.com -f -o allow_other -o dbglevel=debug -o curldbg

參數	說明
-f	以前臺方式而非守護進程方式運行ossfs，在前臺模式下，日志會輸出到終端屏幕。該參數一般用于調試問題時使用。
-o allow_other	賦予計算機上其他用戶訪問掛載目錄的權限，避免前臺掛載ossfs時，出現新的掛載點路徑權限問題。
-o dbglevel=debug	設置ossfs的日志等級為debug。
-o curldbg	打開libcurl的日志信息，用于排查OSS服務端返回的錯誤。

步驟3：分析Debug日志

執行POSIX失敗場景中，需要另起終端執行出錯的指令，并分析執行新打印的ossfs日志。

ossfs自身拋錯

下文以執行chmod -R 777 <業務Pod中的掛載點路徑>指令出錯為例，介紹如何進行問題排查。

由于測試ossfs進程掛載至/test路徑下，則需執行的指令如下。

chmod -R 777 /test

查詢日志，發現掛載點路徑/test下的文件Chmod成功，而Chmod /test本身的錯誤日志如下。

[ERROR] Jul 10 2023:13:03:18:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1742): Could not change mode for mount point.

根據日志信息定位，掛載點路徑不支持通過Chmod變更權限。關于如何修改掛載點的權限，請參見OSS存儲卷FAQ。

說明

根據錯誤日志，可在OSS文檔ossfs常見問題查詢相關解決方法。若未找到相關原因，請提交工單解決。

OSS服務端返回非200錯誤碼

下文以對Bucket中的某個對象進行操作時，都返回錯誤為例，介紹如何進行問題排查。

[INFO]       Aug 23 2022:11:54:11:/tmp/ossfs/src/curl.cpp:RequestPerform(2377): HTTP response code 404 was returned, returning ENOENT, Body Text: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchKey</Code>
  <Message>The specified key does not exist.</Message>
  <RequestId>xxxx</RequestId>
  <HostId><BUCKET>.oss-cn-beijing-internal.aliyuncs.com</HostId>
  <Key><object-name></Key>
  <EC>0026-00000001</EC>
</Error>

執行出錯的指令，發現退出前打印的OSS服務端的返回碼為404，錯誤原因為NoSuchKey，錯誤信息為The specified key does not exist。

根據日志信息定位，該對象在OSS服務端中不存在。關于出現該現象的原因及對應的解決辦法，請參見NoSuchKey。

說明

通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。

CSI Plugin組件為1.26.6及之后的版本

問題現象

業務Pod狀態為Running，但執行讀寫等POSIX指令時ossfs拋錯。

問題原因

執行以下命令，確認ossfs容器是否正常運行。
替換以下<PV_NAME>為實際業務PV的名稱。
CSI版本小于1.30.4時，執行：
```
kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<PV_NAME>
```
CSI版本大于等于1.30.4時，執行：
```
kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<PV_NAME>
```
預期輸出：
```
NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx     1/1    Running              0          5s
```
若ossfs容器運行異常，請先排查容器異常的原因。具體操作，請參見Pod異常問題排查。
通過業務的日志確認發生錯誤的指令及返回的錯誤類型。例如，執行chmod -R 777 /mnt/path指令時返回I/O error。

出現此類事件的原因：CSI組件在拉起ossfs容器后，ossfs Pod正常運行，并在業務Pod所在節點指定的掛載點路徑上掛載OSS Bucket，但在執行chmod、read、open等POSIX指令時，ossfs運行異常并返回錯誤，并在日志中打印對應錯誤。

解決方案

執行以下命令，查詢ossfs容器日志。
CSI版本小于1.30.4時，執行：
```
kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx 
```
CSI版本大于等于1.30.4時，
```
kubectl -n ack-csi-fuse logs -p csi-fuse-ossfs-xxxx 
```
（可選）如果日志為空，或信息過少無法定位問題，說明日志等級過高，需要通過以下方式增加相關配置。
說明
該方式無需重新部署新的Debug存儲卷及對應的存儲聲明，但無法直獲取OSS側的rest請求響應。
1. 創建用于Debug的OSS存儲卷，在原存儲卷配置的基礎上，在otherOpts字段中增加-o dbglevel=debug -o curldbg。使用新建的OSS存儲卷掛載后，通過kubectl logs指令從ossfs Pod獲取Debug日志。Debug日志量較大，僅建議在Debug場景使用。
2. 使用以下內容，在kube-system空間創建名為csi-plugin的ConfiMap。將日志等級設為debug。
  說明
  CSI plugin 1.28.2及之前的版本，日志等級只能設置到info。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: csi-plugin
  namespace: kube-system
data:
  fuse-ossfs: |
    dbglevel=debug # 日志  level
```
  重啟應用所在節點的csi-plugin Pod及csi-provisioner的所有Pod，使Configmap的配置生效，重啟應用Pod觸發重掛載，并確認重掛載后的csi-fuse-ossfs-xxxx重新部署。
  重要
  ConfigMap為全局配置，Debug完成后，請刪除該ConfigMap，再次重啟節點的csi-plugin Pod及csi-provisioner的所有Pod以關閉Debug日志。最后重啟應用Pod再次觸發重掛載，避免ossfs產生大量Debug日志。
分析ossfs容器日志。
通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯和ossfs向OSS服務端發送請求后收到非200錯誤碼。以下通過兩種拋錯類型的示例介紹通用的排查方法。
ossfs自身拋錯
此處以執行chmod -R 777 <業務Pod中的掛載點路徑>指令出錯為例，介紹如何進行問題排查。
1. 若測試ossfs的掛載路徑為/test，則執行以下命令。
```
chmod -R 777 /test
```
  查詢日志后，發現掛載點路徑/test下的文件Chmod成功，而Chmod /test自身的錯誤日志如下。
```
[ERROR]  2023-10-18 06:03:24:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1745): Could not change mode for mount point.
```
  根據日志信息定位，掛載點路徑不支持通過Chmod變更權限。關于如何修改掛載點的權限，請參見OSS存儲卷FAQ。
  說明
  根據錯誤日志，可在OSS文檔ossfs常見問題查詢相關解決方法。若未找到相關原因，請提交工單解決。
OSS服務端返回非200錯誤碼
下文以對Bucket中的某個對象進行操作時，都返回錯誤為例，介紹如何進行問題排查。
```
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:HeadRequest(3014): [tpath=/xxxx]
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:PreHeadRequest(2971): [tpath=/xxxx][bpath=][save=][sseckeypos=-1]
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:prepare_url(4660): URL is http://oss-cn-beijing-internal.aliyuncs.com/<bucket>/<path>/xxxxx
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:prepare_url(4693): URL changed is http://<bucket>.oss-cn-beijing-internal.aliyuncs.com/<path>/xxxxx
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:RequestPerform(2383): HTTP response code 404 was returned, returning ENOENT, Body Text:
```
執行出錯的指令，發現退出前打印的OSS服務端的HTTP返回碼為404。推斷原因為該對象在OSS服務端中不存在。關于出現該現象的原因及對應的解決辦法，請參見404錯誤。
說明
通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。
其他說明
- 如果您的日志等級過高，無法定位問題，并且包含以下需求：
  - 不希望重建OSS存儲卷。
  - 擔心全局ConfigMap配置影響其他問題，例如，Debug期間可能發生的其他OSS存儲卷的掛載或卸載。
  此時，您可以以前臺方式掛載ossfs并獲取Debug日志進行定位。具體操作，請參見CSI Plugin組件為1.26.6之前的版本問題的處理。
  重要
  ossfs容器化運行后，節點未默認安裝ossfs。手動安裝的ossfs版本與實際Pod中運行的ossfs版本可能不一致，建議您優先參考上述解決方案，通過變更PV掛載參數或全局ConfigMap配置的方式進行排查。
- 執行以下操作掛載ossfs：
  1. 安裝最新版本的ossfs。安裝方法，請參見安裝ossfs。
  2. 在節點上執行以下操作，獲取PV名稱的sha256值：
```
echo -n "<pv-name>" | sha256sum
```
    如對"pv-oss"，預期輸出為：
```
8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928
```
  3. 在節點上執行以下操作，獲取ossfs的掛載參數：
```
ps -aux | grep <sha256-value>
```
    預期輸出中包含ossfs的進程記錄。
  4. 在節點上執行以下命令，生成ossfs掛載時需要的鑒權信息。在Debug之后，請您及時清理該文件。
```
mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs
```

日本熟妇hd丰满老熟妇,中文字幕一区二区三区在线不卡 ,亚洲成片在线观看,免费女同在线一区二区

ossfs異常問題排查

排查說明

適用場景1：掛載失敗

CSI Plugin組件為1.26.6之前的版本

問題現象

問題原因

解決方案

步驟1：獲取原ossfs啟動指令

步驟2：前臺掛載ossfs并獲取Debug日志

步驟3：分析Debug日志

ossfs自身拋錯

OSS服務端返回非200錯誤碼

CSI Plugin組件為1.26.6及之后的版本

問題現象

問題原因

解決方案

ossfs自身拋錯

OSS服務端返回非200錯誤碼

其他說明

適用場景2：執行POSIX指令拋錯

CSI Plugin組件為1.26.6之前的版本

問題現象

問題原因

解決方案

步驟1：獲取原ossfs啟動指令

步驟2：前臺掛載ossfs并獲取Debug日志

步驟3：分析Debug日志

ossfs自身拋錯

OSS服務端返回非200錯誤碼

CSI Plugin組件為1.26.6及之后的版本

問題現象

問題原因

解決方案

ossfs自身拋錯

OSS服務端返回非200錯誤碼

其他說明