并發訪問同一文件時，服務器端出現無響應35s現象，該如何處理？

原因：當前Linux SMB內核驅動有缺陷，會造成在使用vers=2.1或者3.0掛載時，在某些并發場景不能發出服務器端期待的SMB BreakAck協議包，導致服務器端無響應35s。

解決方案一：掛載文件系統時，使用vers=2.0協議。

解決方案二：執行以下操作。

1. 在加載CIFS模塊時，禁用oplocks，執行以下命令。

   # modprobe cifs enable_oplocks=0

2. 當CIFS模塊加載完成時，禁用oplocks，執行以下命令。

   # echo 0 > /sys/module/cifs/parameters/enable_oplocks

3. 檢查oplocks的狀態，執行以下命令。

   # cat /sys/module/cifs/parameters/enable_oplocks

   輸出結果中，Y代表啟用（enabled）。N代表禁用（disabled）。

   說明

   • 為了使以上的修改生效，請卸載并重新掛載SMB協議文件系統。

   • 如果您想使以上的修改永久生效，請創建文件/etc/modprobe.d/cifs.conf并添加命令行options cifs enable_oplocks=0。

為什么無法創建符號鏈接文件？

問題原因

Linux掛載SMB協議文件系統時沒有選擇mfsymlinks選項，或者使用了2.0協議版本掛載。

解決方案

Linux掛載SMB協議文件系統時，使用2.1或3.0協議版本并添加mfsymlinks選項。掛載命令示例如下，示例中的參數說明，請參見SMB（Linux）掛載命令參數說明。

sudo mount -t cifs //file-system-id.region.nas.aliyuncs.com/myshare /mnt -o vers=2.1,guest,uid=0,gid=0,dir_mode=0755,file_mode=0755,mfsymlinks,cache=strict,rsize=1048576,wsize=1048576

為什么SMB協議文件系統掛載點無響應？

問題原因

在Linux內核為3.10.0-514之前的Linux分發版中，SMB內核驅動在并發場景有時會crash（內核stack如下所示），導致掛載點無法被訪問。內核日志中有如下類似信息：

...
[<ffffffffc03c9bc1>] cifs_oplock_break+0x1f1/0x270 [cifs]
[<ffffffff810a881a>] process_one_work+0x17a/0x440
[<ffffffff810a8d74>] rescuer_thread+0x294/0x3c0
...

解決方案

• 使用cache=none重新掛載（性能會受影響）。

• 升級云服務器ECS（Linux）的操作系統。

拷貝大文件時報"cp: error writing '</path/to/file>': Bad file descriptor"，該如何處理？

問題原因

網絡或者后端有臨時小故障發生，某些Linux分發版（如Suse）的SMB客戶端功能較弱，不能很好的支持這種故障切換。

解決方案

建議選用NAS SMB推薦的Linux版本，NAS SMB支持的Linux操作系統版本如下表所示：

為什么寫入文件系統的中文字符在客戶端顯示為亂碼?

問題現象

在Linux或Windows客戶端向NAS文件系統寫入的中文字符（文件名、內容等）在另一個平臺客戶端顯示為亂碼。

問題原因

Windows客戶端中文編解碼默認使用GBK字符集，Linux客戶端中文編解碼默認使用UTF-8字符集，寫入NAS文件系統的數據為平臺對應字符集編碼后的內容。在另一平臺讀取時需要進行解碼，因為兩個平臺字符集并不兼容，故無法正常解碼，導致顯示內容為不可識別的亂碼。

解決方案

建議您使用Windows客戶端掛載SMB協議NAS文件系統，Linux客戶端掛載NFS協議文件系統，從而規避平臺不兼容問題。

為什么Windows掛載NFS協議文件系統創建和打開文件時速度緩慢？

問題原因

Windows上使用NFS協議實例，會存在大小寫敏感和大小寫不敏感的兼容性問題，在目錄里創建文件的性能隨著目錄規模增大而明顯下降，原因是每次創建一個文件都需要對目錄進行遍歷，當目錄規模達到10萬級別時，目錄遍歷一次需要10秒鐘以上。

解決方案

修改掛載參數，增加-o casesensitive=yes字段，避免目錄遍歷。掛載命令如下所示：

mount -o nolock -o mtype=hard -o timeout=60 -o casesensitive=yes \\file-system-id.region.nas.aliyuncs.com\! Z:

請根據實際情況替換盤符Z和掛載點地址file-system-id.region.nas.aliyuncs.com。

如何解決Windows客戶端對NFS協議文件系統中的文件重命名時返回的invalid device錯誤？

如果NFS協議文件系統是掛載在文件系統的子目錄上，當執行文件重命名操作時，會返回的invalid device錯誤，請您將文件系統掛載在文件系統的根目錄上。具體操作，請參見步驟二：掛載NFS協議的通用型NAS文件系統。

如何解決在NFS協議文件系統中創建文件延遲問題？

• 問題現象：

  ECS-1創建了文件abc，但是ECS-2需要過一段時間才能看到ECS-1創建的文件abc，有時會延遲1s，有時甚至會到1分鐘，這是為什么？

• 問題原因：

  這是Lookup Cache導致的，符合預期T時間。例如，ECS-2在ECS-1創建文件abc前進行了訪問，導致ECS-2發生文件不存在，于是緩存了一條文件abc不存在的記錄。在T時間內，由于FileAttr還沒有過期，ECS-2再次訪問時，仍會訪問第一次緩存到文件abc不存在的記錄。

• 解決方案：

  如果要保證ECS-1創建文件后，ECS-2立即就能看到它，可以使用如下方案：

  • 方案一：關閉ECS-2的Negative Lookup Cache，不緩存不存在的文件。該方案開銷最小。

    掛載時，添加lookupcache=positive（默認值lookupcache=all）字段，掛載命令如下所示：

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,lookupcache=positive file-system-id.region.nas.aliyuncs.com:/ /mnt

  • 方案二：關閉ECS-2的所有緩存。該方案會導致性能非常差，請根據業務實際情況選擇合適的方案。

    掛載時，添加actimeo=0字段，掛載命令如下所示：

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

如何解決向NFS協議文件系統中寫入數據延遲問題？

• 問題現象：

  ECS-1更新了文件abc，但是ECS-2立即去讀它，仍然是舊的內容，這是為什么？

• 問題原因：

  涉及如下兩個原因。

  • 第一個原因：ECS-1寫了abc后，不會立即flush，會先進行PageCache，依賴應用層調用fsync或者close。

  • 第二個原因：ECS-2存在文件Cache，可能不會立即去服務端取最新的內容。例如，ECS-2在ECS-1更新文件abc之時，就已經緩存了數據，當ECS-2再次去讀時，仍然使用了緩存中的內容。

• 解決方案：

  如果要保證ECS-1創建文件后，ECS-2立即就能看到它，可以使用如下方案：

  • 方案一：CTO一致性，讓ECS-1或ECS-2的讀寫符合CTO模式，則ECS-2一定能讀到最新數據。具體來說，ECS-1更新文件后，一定要執行close或者執行fsync。ECS-2讀之前，重新open，然后再去讀。

  • 方案二：關閉ECS-1和ECS-2的所有緩存。該方案會導致性能非常差，請根據業務實際情況選擇合適的方案。

    • 關閉ECS-1的緩存。掛載時，添加noac字段，保證所有寫入立即落盤。掛載命令如下所示：

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,noac file-system-id.region.nas.aliyuncs.com:/ /mnt

      說明

      • 如果ECS-1的寫操作完成后會調用fsync，或者使用sync寫，可以將上面的noac替換為actimeo=0，性能會稍好一點。

      • noac等價于actimeo=0加sync（即，強制所有寫入都為sync寫）。

    • 關閉ECS-2的緩存。掛載時，添加actimeo=0字段，忽略所有緩存。掛載命令如下所示：

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

為什么兩臺ECS實例在查詢NAS文件系統中同一文件時，文件的屬主不同？

在文件系統中，標識用戶身份的不是用戶名，而是UID或GID，您在ECS實例查詢的屬主用戶名是由UID信息轉換得到的，當同一UID在不同ECS實例中信息轉換為不同的用戶名，則會被認為是不同的屬主。

例如，在ECS實例1中使用admin用戶創建文件admin_on_machine1，在ECS實例2中使用admin用戶創建文件admin_on_machine2。在ECS實例1中執行ll命令，查看已創建的文件，如下圖所示：在ECS實例2中執行ll命令，查看已創建的文件，如下圖所示：通過兩臺ECS實例查詢可以看到，同一文件的屬主用戶名不一致。

然后，分別執行id命令，查詢admin用戶信息。如下圖所示ECS實例1中admin用戶的UID為505：如下圖所示ECS實例2中admin用戶的UID為2915：如下圖所示執行stat admin_on_machine1 admin_on_machine2命令，查詢到兩個文件屬于不同的UID：

如何避免多進程或多客戶端并發寫同一日志文件可能出現的異常？

問題現象

文件存儲NAS為多客戶端提供了統一命名空間的文件共享讀寫能力，但在多進程或多客戶端并發寫同一個文件的場景中（典型的例如并發寫同一個日志文件），各進程分別維護了獨立的文件描述符及寫入位置等上下文信息，而NFS協議本身并沒有提供Atomic Append語義的支持，因此可能會出現寫覆蓋、交叉、串行等異常現象。

解決方案

• （推薦）不同進程或不同客戶端寫入同一文件系統的不同文件中，后續分析處理時再進行歸并，這個方案能夠很好地解決并發寫入導致的問題，同時無需使用文件鎖，不會對性能造成影響。

• 對于并發追加寫同一個文件（如日志）的場景，可以使用文件鎖+seek機制來保證寫入的原子性和一致性。但是文件鎖+seek是一個比較耗時的操作，可能會對性能產生顯著的影響。下面將對這種方式進行一個簡單的介紹，以供參考。

flock+seek使用方法

由于NFS協議本身沒有提供對Atomic Append語義的支持，因此當并發寫入同一文件末尾（如日志）時，很可能會出現相互覆蓋的情況。在Linux中，通過使用flock+seek的方式，可以在NFS協議文件系統上做到模擬Atomic Append，對并發追加寫入同一文件提供保護和支持。

使用方式如下：

1. 調用fd=open(filename, O_WRONLY | O_APPEND | O_DIRECT) 以追加寫的方式打開文件，并且指定 O_DIRECT（直寫，不通過 Page Cache），獲得文件描述符fd。

2. 調用flock(fd, LOCK_EX|LOCK_NB)嘗試獲取文件鎖，如果獲取失敗（如鎖已被占用）則會返回錯誤，此時可以繼續重試或進行錯誤處理。

3. 文件鎖獲取成功后，調用lseek(fd, 0, SEEK_END)將fd當前的寫入偏移定位到文件末尾。

4. 執行正常的write操作，此時寫入位置應該是文件的末尾，并且由于有文件鎖的保護，不會出現并發寫入相互覆蓋的問題。

5. 寫操作執行完成后，調用flock(fd, LOCK_UN)釋放文件鎖。

使用Linux操作系統在NFS協議文件系統中執行ls命令時，為什么會返回523錯誤？

問題現象

Linux客戶端在NFS協議文件系統中執行ls命令時，返回如下報錯信息。

原因分析

對文件系統目錄下執行ls時，該目錄有并發的rename操作，則會返回523錯誤。

解決方案

稍等重試即可。如果還出現類似報錯，請聯系NAS技術支持進行咨詢。

為什么SMB協議文件系統掛載有時候連接不上？

問題現象

當您混用NFS和SMB協議文件系統，導致第一次通過net use命令掛載NFS協議文件系統連接失敗后，掛載正確的SMB協議文件系統也會出現問題。

解決方案

檢查確保掛載正確的文件系統后，暫時停止掛載，5分鐘后再次掛載。如果還失敗，請聯系NAS技術支持進行咨詢。

為什么Administrator能看見掛載的SMB目錄，其他用戶看不到？

該現象是由于Windows的用戶隔離機制造成的。即一個登錄用戶的已掛載目錄在另一個用戶的登錄界面中不會顯示。

要實現多用戶的共享，需要創建一個目錄鏈接。比如C盤下創建一個myshare，命令如下：

mklink /D C:\myshare \\xxxxxxx-xxxx.cn-beijing.nas.aliyuncs.com\myshare\

如何解決Linux掛載SMB協議文件系統性能不佳？

如果SMB協議文件系統性能不佳，您可以從以下方面進行排查。

• 原因1：SMB單個文件系統的吞吐能力與存儲量是相聯系的。單文件系統的吞吐（讀+寫）上限與當前存儲量呈線性關系。

  解決方案：使用fio工具來測試SMB協議文件系統性能。具體操作，請參見NAS性能測試。

• 原因2：云服務器ECS（Linux）的單機網絡帶寬較小。

  解決方案：使用多個云服務器ECS（Linux）達到文件系統的總體預期性能。

• 原因3：禁用了SMB協議文件系統的客戶端緩存。

  解決方案：在掛載SMB協議文件系統時，cache=none表示禁用緩存，默認或者cache=strict表示使用緩存；您可以通過sudo mount | grep cifs命令檢查所用的選項是否正確。

• 原因4：沒有設置合適的SMB客戶端的I/O大小。

  解決方案：根據業務需求調整rsize及wsize，默認值：1048576。

• 原因5：云服務器ECS（Linux）的CPU或內存的規格過低，或被其它業務占用過多。

  解決方案：選擇合適的云服務器ECS（Linux）規格、檢查系統其它應用資源，確保系統滿足CPU和內存要求。您可以通過top命令檢查系統CPU、MEM使用情況。

• 原因6：掛載時使用了atime選項。

  解決方案：如果您的業務不是對文件的訪問時間（atime）極為敏感，請不要在掛載時使用atime選項。

• 原因7：遇到大量小文件頻繁讀、少量寫但需要寫時通知的WebServer場景。

  解決方案：您可以在客戶端配置該WebServer（如Apache）產品特定的緩存機制或者聯系阿里云NAS團隊開通WebServer場景加速功能。

Linux訪問SMB協議文件系統時，報Permission denied錯誤，該怎么解決？

原因：Linux管理員在掛載時使用了不正確的UID、GID、file_mode、dir_mode。

解決方案：檢查是否正確設置了UID、GID、file_mode、dir_mode等掛載選項。更多信息，請參見掛載SMB協議文件系統。

如何變更SMB協議文件系統中文件名大小寫？

SMB協議文件系統對文件名大小寫不敏感，和Windows系統保持一致。但在文件名大小寫改名這個場景暫時沒有支持。

您可以先從大寫文件名改成一個其它名字的文件，再改成小寫文件名，反之亦然。

為什么不能改變文件owner，文件和目錄mode？

現在暫時不支持動態改變，只能在掛載時指定。更多信息，請參見掛載SMB協議文件系統。

后綴為.nfs的文件是怎么產生的？如何刪除？

在應用程序已經打開某文件時，如果刪除該文件，則會產生后綴為.nfs的臨時文件。當訪問進程關閉后，該臨時文件將自動被刪除。

訪問NAS文件系統目錄下的文件時，返回bind conn to session failed on NFSv4 server該如何解決？

• 問題原因

  由于文件存儲NAS不支持NFSv4.1協議，當您使用NFSv4.1協議掛載文件系統時產生該報錯。

• 解決方案

  請您根據業務場景選擇使用NFSv3或NFSv4.0協議重新掛載文件系統。更多信息，請參見掛載文件系統場景說明。

如何處理多個ECS實例掛載同一NFS協議文件系統出現數據不同步的情況？

問題現象

NAS在多掛載點的情況下，不同客戶端進行實時同步時存在較長時間延遲的問題。

問題原因

操作系統kernel默認對文件和目錄的屬性進行維護，將其生成一份metadata緩存，以減少NFSPROC_GETATTR遠程過程調用的需求。

解決方案

執行以下掛載命令，禁用文件和目錄屬性的緩存。

mount -t nfs4 -o noac file-system-id.region.nas.aliyuncs.com:/ /mnt

其中，file-system-id.region.nas.aliyuncs.com為文件系統掛載點地址，請根據實際值替換；/mnt ：當前服務器上待掛載的本地路徑，請根據實際情況替換路徑。

為什么卸載舊NAS并重新掛載新NAS后，容器Pod仍將數據寫入舊NAS？

問題原因

將NAS掛載到ECS并通過本地存儲卷（HostPath）映射的方式將NAS的掛載目錄映射到容器時，容器中的掛載信息獨立于ECS，ECS后續對NAS掛載目錄進行卸載或者掛載新NAS時，已經啟動的容器仍然會使用其啟動時掛載的舊NAS。

解決方案

在ECS上重新掛載新NAS后，重啟容器Pod。

服務器重啟或停機后，為什么NAS里的文件看不到了？

如果文件系統仍存在，此原因一般是服務器未配置自動掛載NAS。

如何手動再次掛載NAS請參考掛載文件系統場景說明。

如需實現重啟后NAS自動掛載功能，請參考以下文檔：

• Linux系統自動掛載NFS協議文件系統

• Windows系統自動掛載SMB協議文件系統

為什么Linux掛載SMB協議文件系統遷移和復制文件時速度緩慢？

如果已經排除了文件系統本身的性能問題，則可能原因是您沒有使用并發式遷移或復制文件。您可以通過以下開源工具進行遷移或復制。

• GNU Parallel

  根據系統資源，選擇合適的線程數。示例：find * -type f | parallel --will-cite -j 10 cp {} /mnt/smb/ &

• Fpart

• Fpsync

• multi

為什么向文件系統寫入數據時，返回Disk quota exceeded錯誤信息？

• 問題原因

  目標目錄的使用量或文件數超過了設定的用戶配額限制，因此導致寫入操作（包括增加文件長度、創建文件、目錄、移動文件到目錄等操作）失敗，返回類似Disk quota exceeded的錯誤信息。

• 解決方案

  1. 建議您盡快清理數據釋放空間，或者提升該目錄的容量限制。具體操作，請參見編輯單條用戶配額。

  2. 清理完成后，建議先對配額的目錄執行測試性的寫操作（例如，創建并寫數據到測試文件）來觸發配額緩存的異步刷新，判斷這些測試性寫操作能夠成功，然后再重新啟動業務。

如何解決訪問NFS協議文件系統時，返回無訪問權限問題？

您可參照以下操作步驟為系統配置AnonymousGID和AnonymousUID。

1. 登錄掛載文件系統的ECS服務器。

2. 打開命令提示符，執行regedit命令，進入注冊表編輯器頁面。

3. 選擇HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > ClientForNFS > CurrentVersion > Default。

4. 右擊空白處，選擇新建 > DWORD（32位）值，并創建以下兩個注冊表項。

   • AnonymousGID，值為0。

   • AnonymousUID，值為0。

5. 重啟ECS實例。

6. 重新掛載NFS協議的通用型NAS文件系統。

   mount -o nolock -o mtype=hard -o timeout=60 \\file-system-id.region.nas.aliyuncs.com\! Z:

   請根據實際情況替換盤符Z:和掛載點域名file-system-id.region.nas.aliyuncs.com。

7. 執行mount檢查是否掛載成功。

   掛載完成后，回顯信息必須包括mount=hard、locking=no以及timeout參數>=10，否則說明掛載有問題。

   

能否通過執行chown修改NAS根目錄權限？

當前不允許用戶修改NAS根目錄權限。

如果您希望控制本地掛載的NAS目錄的權限，可以考慮使用子目錄掛載的方式。例如，如果將NAS根目錄掛載到本地的/data目錄，將無法通過chown修改/data目錄的屬主和屬組。如果將NAS子目錄（需提前創建）掛載到本地的/data目錄，即可以通過chown修改/data目錄的屬主和屬組。需要注意的是，在NAS中創建子目錄時，仍需要先掛載NAS根目錄后創建。關于如何創建子目錄并完成掛載，請參見如何在Linux系統中創建NAS子目錄并完成掛載？。