共用方式為

關於 Azure 檔案儲存體和 Azure 檔案同步的常見問題集 (FAQ)

  • 發行項

Azure 檔案儲存體提供雲端中完全受控的檔案共用，可透過業界標準伺服器訊息區 (SMB) 通訊協定及網路檔案系統 (NFS) 通訊協定來存取。 您可以同時在 Windows、Linux 和 macOS 的雲端或內部部署上掛接 Azure 檔案共用。 您也可以使用 Azure 檔案同步，在接近使用資料之處進行快速存取，藉以在 Windows Server 電腦上快取 Azure 檔案共用。

Azure 檔案同步

  • 相同的同步群組中是否可以同時有已加入網域和未加入網域的伺服器？
    是。 同步群組可以包含具有不同 Active Directory 成員資格的伺服器端點，即使它們是未加入網域的端點也一樣。 雖然就技術上來說，這樣的設定是可行的，但我們不建議您將此作為一般設定，因為針對某部伺服器上的檔案和資料夾所定義的存取控制清單 (ACL)，可能無法由同步群組中的其他伺服器強制執行。 為獲得最佳結果，建議您在相同 Active Directory 樹系的伺服器之間、在位於不同 Active Directory 樹系但已建立信任關係的伺服器之間，或是在不在網域中的伺服器之間進行同步。 我們建議您避免混用這些設定。

  • zure 檔案共用中使用 SMB 建立了檔案，或是在入口網站中建立了檔案。將該檔案與同步群組中的伺服器進行同步，需要花費多少時間？

    不會立即偵測及複寫使用 Azure 入口網站或 SMB 對 Azure 檔案共用所做的變更，和伺服器端點的變更不一樣。 Azure 檔案還沒有變更通知或日誌功能，因此無法在檔案變更時自動啟動同步工作階段。 在 Windows Server 上，Azure 檔案同步會使用 Windows USN 日誌，在檔案變更時自動啟動同步工作階段。

    若要偵測 Azure 檔案共用的變更，Azure 檔案同步有個已排程的作業，稱為「變更偵測作業」。 變更偵測作業會列舉檔案共用的每個檔案，然後比較該檔案的同步版本。 當變更偵測作業判斷檔案已有變更時，Azure 檔案同步就會起始同步工作階段。 變更偵測作業會每隔 24 小時起始。 由於變更偵測作業的運作方式是列舉 Azure 檔案共用的每個檔案，大命名空間會比小命名空間耗費更長的時間。 大命名空間判斷哪些檔案已變更所耗費的時間，可能會超過 24 小時 (每隔 24 小時執行一次偵測作業)。

    若要立即同步處理 Azure 檔案共用中變更的檔案，您可以使用 Invoke-AzStorageSyncChangeDetection PowerShell Cmdlet，手動在 Azure 檔案共用中起始變更偵測。 此 Cmdlet 是用於在 Azure 檔案共用中以自動化程序進行變更，或是由系統管理員完成變更的案例 (例如將檔案和目錄移到共用中)。 至於終端使用者變更，建議您在 IaaS VM 中安裝 Azure 檔案同步代理程式，並讓使用者透過 IaaS VM 存取檔案共用。 如此一來，所有變更都會快速同步處理至其他代理程式，而不需要使用 Invoke-AzStorageSyncChangeDetection Cmdlet。 若要深入瞭解，請參閱 Invoke-AzStorageSyncChangeDetection 文件。

    我們發現，為 Azure 檔案新增變更偵測，類似於在 Windows 伺服器上磁碟區的 USN 變更偵測。 請至 Azure 社群意見反應投票，協助我們決定此功能後續的開發優先順序。

  • 如果同一個檔案近乎同時地在兩部伺服器上進行變更，會發生什麼事？
    當 Azure 檔案共用中的檔案與伺服器端點位置中的檔案不相符 (大小和/或上次修改時間不同) 時，就會產生檔案衝突。

    下列案例可能會導致檔案衝突：

    • 在端點中建立或修改檔案 (例如伺服器 A)。 如果先在不同的端點上修改相同的檔案，然後將伺服器 A 的變更同步至該端點，則會建立衝突檔案。
    • 在建立伺服器端點之前，檔案存在於 Azure 檔案共用和伺服器端點位置中。 如果建立伺服器端點時，伺服器上的檔案與 Azure 檔案共用之間的檔案大小和/或上次修改時間不同，則會建立衝突檔案。
    • 由於已達到損毀或知識限制而重建同步資料庫。 重建資料庫後，同步處理就會進入稱為調節的模式。 如果在發生調節時，伺服器上的檔案與 Azure 檔案共用之間的檔案大小和/或上次修改時間不同，則會建立衝突檔案。

    完成初次上傳至 Azure 檔案共用後，Azure 檔案同步即不會覆寫同步群組中的任何檔案。 而是會使用簡單的衝突解決策略：這會針對同時在兩個端點中變更的檔案，保留這兩個檔案的變更。 最新寫入的變更會保留原始檔案名稱。 較舊的檔案 (由 LastWriteTime 決定) 會將端點名稱和衝突號碼附加至檔案名稱。 若為伺服器端點，端點名稱是伺服器的名稱。 若為雲端端點，端點名稱為雲端。 名稱會遵循此分類法：

    <FileNameWithoutExtension>-<endpointName>[-#].<ext>

    例如，如果 CentralServer 是發生較舊寫入的位置，則 CompanyReport.docx 的第一個衝突會變成 CompanyReport CentralServer.docx。 第二個衝突會命名為 CompanyReport-CentralServer-1.docx。 Azure 檔案同步支援每個檔案 100 個衝突檔案。 一旦達到衝突檔案數目上限，檔案就無法同步，直到衝突檔案的數目小於 100 為止。

  • 我已停用雲端分層，為什麼在伺服器端點位置還有分層的檔案？
    伺服器端點位置存在分層檔案的原因有兩個：

    • 將新的伺服器端點加入現有的同步群組時，如果您選擇初始下載模式的「先重新叫用命名空間」選項或「僅重新叫用命名空間」選項，檔案將會以分層顯示，直到在本機下載為止。 若要避免這種情況，請在初次下載模式中選取 [避免分層檔案] 選項。 若要手動回收檔案，請使用 Invoke-StorageSyncFileRecall cmdlet。

    • 如果在伺服器端點上啟用雲端階層處理，然後又停用該選項，則檔案會在存取之前維持分層狀態。

  • 為什麼我的分層檔案在 Windows 檔案總管中沒有顯示縮圖或預覽？
    若為分層檔案，伺服器端點不會顯示縮圖和預覽。 這是預期的行為，因為 Windows 的縮圖快取功能刻意略過讀取具有離線屬性的檔案。 啟用雲端階層處理時，透過分層檔案讀取會導致檔案下載 (重新叫用)。

    這不是 Azure 檔案同步特有的行為。Windows 檔案總管會針對已設定離線屬性的任何檔案顯示「灰色 X」。 透過 SMB 存取檔案時，您會看到 X 圖示。 如需此行為的詳細說明，請參閱為何標示離線的檔案沒有顯示縮圖？

    若您有如何管理分層檔案的相關問題，請參閱如何管理分層檔案。

  • 分層的檔案為何存在於伺服器端點命名空間以外？
    在 Azure 檔案同步代理程式版本 3 之前，Azure 檔案同步會禁止移動位於伺服器端點以外外、但與伺服器端點位於相同磁碟區上的分層檔案。 非分層檔案的複製作業和移動，以及從分層檔案移動到其他磁碟區的移動，均不受影響。 之所以會有此行為，是因為系統隱含地假設在相同磁碟區上執行這些移動作業的檔案總管和其他 Windows API (幾近於) 是 即時的重新命名作業。 這表示，當 Azure 檔案同步回復雲端中的資料時，移動作業將會使檔案總管或其他的移動方法 (例如命令列或 PowerShell) 呈現為無回應的狀態。 從 Azure 檔案同步代理程式 3.0.12.0 版開始，Azure 檔案同步將可讓您移動伺服器端點以外的分層檔案。 我們讓分層的檔案以分層的形式存在於伺服器端點以外，然後在背景中回復檔案，以避免產生負面影響。 這表示，相同磁碟區上的移動會即時執行，而我們會在移動完成後，再執行所有將檔案回復至磁碟的工作。

  • 我在伺服器上的 Azure 檔案同步有問題 (同步、雲端分層等)。我是否應移除並重新建立伺服器端點？

    否：移除伺服器端點不像是重新啟動伺服器！ 要解決同步處理、雲端層或其他方面的 Azure 檔案同步等問題，將伺服器端點移除然後再加以重新建立通常不是適當的解決方案。移除伺服器端點是破壞性行為。 若分層檔案存在於伺服器端點命名空間外部，這種做法可能會導致資料遺失。 如需詳細資訊，請參閱為什麼分層檔案存在於伺服器端點命名空間外部。 或者，此做法也可能會造成無法存取存在於伺服器端點命名空間中的分層檔案。 重建伺服器端點並無法解決這些問題。 分層的檔案可能會位於您的伺服器端點命名空間內部，即使您從未啟用過雲端分層。 因此，建議您不要移除伺服器端點，除非您要停止使用與此特定資料夾進行 Azure 檔案同步，或是已收到 Microsoft 工程師的明確指示，要執行這項操作。 如需關於移除伺服器端點的詳細資訊，請參閱移除伺服器端點。

  • 我可以將儲存體同步服務和/或儲存體帳戶移至不同的資源群組、訂用帳戶，或 Microsoft Entra 租用戶嗎？
    可以，您可以將儲存體同步服務和/或儲存體帳戶移至不同的資源群組、訂用帳戶，或 Microsoft Entra 租用戶。 在您移動儲存體同步服務或儲存體帳戶之後，您需要將儲存體帳戶的存取權提供給 Microsoft.StorageSync 應用程式。 執行下列步驟:

    1. 登入 Azure 入口網站，然後從服務選單中選取 [存取控制 (IAM)]。

    2. 選取 [角色指派] 索引標籤，列出可存取儲存體帳戶的使用者和應用程式 (服務主體)。

    3. 確認 [Microsoft.StorageSync] 或 [混合式檔案同步服務] (舊的應用程式名稱) 出現在清單中，且包含 [讀者及資料存取] 角色。

      如果清單中未顯示 [Microsoft.StorageSync] 或 [混合式檔案同步服務]，請執行下列步驟：

      • 選取 [新增]。
      • 在 [角色] 欄位中，選取 [讀者及資料存取]。
      • 在 [選取] 欄位中，輸入 Microsoft.StorageSync，選取角色並選取 [儲存]。

      注意

      建立雲端端點時，儲存體同步服務和儲存體帳戶必須位於相同的 Microsoft Entra 租用戶中。 建立雲端端點之後，可以將儲存體同步服務和儲存體帳戶移至不同的 Microsoft Entra 租用戶。

  • Azure 檔案同步是否會在 Azure 檔案中隨著資料保留目錄/檔案層級 NTFS AC？

    從 2020 年 2 月 24 日起，Azure 檔案同步所分層的新和現有 ACL 會以 NTFS 格式保存，而且直接對 Azure 檔案共用所做的 ACL 修改將會同步至同步群組中的所有伺服器。 ACL 上對 Azure 檔案儲存體共用進行的任何變更，都會透過 Azure 檔案同步進行同步處理。將資料複製到 Azure 檔案儲存體時，請務必使用支援必要「精確度」的複製工具，將屬性、時間戳記和 ACL 複製到 Azure 檔案共用，不論是透過 SMB 還是 REST。 使用 Azure 複製工具 (例如 AzCopy) 時，請務必使用最新版本。 請檢查檔案複製工具表格以取得 Azure 複製工具概觀，確保您可以複製檔案的所有重要中繼資料。

    如果您已在 Azure 檔案同步受控檔案共用上啟用 Azure 備份，則檔案 ACL 可以繼續進行還原，做為備份還原工作流程的一部分。 這適用於整個共用或個別檔案/目錄。

    如果您是針對 Azure 檔案同步管理的檔案共用使用快照集，做為自我管理備份解決方案的一部分，則若在 2020 年 2 月 24 日之前取得快照集，您的 ACL 可能無法正確地還原為 NTFS ACL。 如果發生這種情況，請考慮連絡 Azure 支援。

  • Azure 檔案同步是否會同步處理目錄的 LastWriteTime？為什麼當目錄內的檔案變更時，目錄上的 [修改日期] 時間戳記沒有更新？
    否，Azure 檔案同步不會同步目錄的 LastWriteTime。 此外，當目錄內的檔案變更時，Azure 檔案儲存體不會更新目錄的 [修改日期] 時間戳記 (LastWriteTime)。 這是預期行為。

  • 為什麼 AFS 伺服器上的防病毒軟體會回收階層式檔案？
    當使用者存取階層式檔案時，某些防病毒軟體 (AV) 軟體可能會導致非預期的檔案回收。 如果未將 AV 軟體設定為忽略階層式檔案 (具有 RECALL_ON_DATA_ACCESS 屬性的檔案)，就會發生這種情況。 發生的狀況如下：

    1. 使用者嘗試存取階層式檔案。
    2. AV 軟體會封鎖讀取控制代碼。
    3. AV 應用程式接著會執行自己的讀取，以掃描檔案中是否有病毒。

    此程式可能會像 AV 軟體重新叫用階層式檔案一樣，但實際上是由使用者的存取嘗試所觸發。 若要避免此問題，請確定您的 AV 廠商會設定其軟體，以忽略使用 RECALL_ON_DATA_ACCESS 屬性掃描階層式檔案。

  • SSL 檢查軟體是否可以封鎖存取 AFS 伺服器？請確定您的 SSL 檢查軟體 (例如 Zscaler 或 FortiGate) 允許 Azure 檔案同步 (AFS) 伺服器端點存取 Azure。 這些 SSL 檢查工具可以覆寫防火牆設定，並選擇性地允許流量。 請連絡您的網路管理員以解決此問題。 使用「testnet」命令來判斷您的 AFS 伺服器是否遇到此問題。

安全性、驗證和存取控制

  • 我該如何稽核 Azure 檔案儲存體中的檔案存取和變更？

    有兩個選項可提供 Azure 檔案儲存體的稽核功能：

    • 如果使用者直接存取 Azure 檔案共用，則您可以使用 Azure 儲存體記錄來追蹤檔案變更和使用者存取，以進行疑難排除。 系統會以最佳方式來記錄要求。
    • 如果使用者透過已安裝 Azure 檔案同步代理程式的 Windows Server 來存取 Azure 檔案共用，請使用稽核原則或協力廠商產品來追蹤 Windows Server 上的檔案變更和使用者存取。

  • Azure 檔案儲存體是否支援使用存取型列舉 (ABE) 來控制 SMB Azure 檔案共用中的檔案和資料夾可見度？

    目前不支援搭配使用 ABE 與 Azure 檔案儲存體，但您可以搭配使用 DFS-N 與 SMB Azure 檔案共用。

以身分識別為基礎的驗證

  • Microsoft Entra Domain Services 是否支援使用已加入或向 Microsoft Entra ID 註冊之裝置的 Microsoft Entra 認證進行 SMB 存取？

    否，不支援此案例。

  • 我可以使用正式名稱 (CNAME) 在身分識別型驗證時掛接 Azure 檔案共用嗎？

    是，對於 SMB Azure 檔案共用，現在單樹系和多樹系中都支持此案例。 不過，Azure 檔案儲存體僅支援使用儲存體帳戶名稱作為網域前置詞來設定 CNAME。 如果您不想使用儲存體帳戶名稱作為前置詞，請考慮改用 DFS 命名空間。

  • 我是否可以從不同訂用帳戶下的 VM 使用 Microsoft Entra 認證來存取 Azure 檔案共用？

    若檔案共用部署所在的訂用帳戶與和部署到 VM 所加入之網域之 Microsoft Entra Domain Services 相同的 Microsoft Entra 租用戶關聯，則您可以使用相同的 Microsoft Entra 認證來存取 Azure 檔案共用。 不僅訂用帳戶有限制，關聯的 Microsoft Entra 租用戶也有。

  • 我是否可以使用與 Azure 檔案共用主要租用戶不同的 Microsoft Entra 租用戶，啟用 Azure 檔案共用的 Microsoft Entra Domain Services 或內部部署 AD DS 驗證？

    否。 Azure 檔案儲存體只支援使用位於與檔案共用之訂用帳戶相同的訂用帳戶的 Microsoft Entra 租用戶來進行 Microsoft Entra Domain Services 或內部部署 AD DS 整合。 訂用帳戶只能與一個 Microsoft Entra 租用戶相關聯。 使用內部部署 AD DS 進行驗證時，AD DS 認證必須同步至儲存體帳戶與其相關聯的 Microsoft Entra ID。

  • 適用於 Azure 檔案共用的內部部署 AD DS 驗證是否支援使用多個樹系與 AD DS 環境整合？

    Azure 檔案儲存體內部部署 AD DS 驗證只會與儲存體帳戶註冊的網域服務樹系整合。 若要支援來自另一個樹系的驗證，您的環境必須正確地設定樹系信任。 如需詳細指示，請參閱搭配多個 Active Directory 樹系使用 Azure 檔案儲存體。

    注意

    在多樹系設定中，請勿使用 [檔案總管] 在根目錄或檔案層級設定 Windows ACL/NTFS 權限。 請改為使用 icacls。

  • 建立電腦帳戶或服務登入帳戶來代表 AD 中的儲存體帳戶，是否有任何差異？

    建立電腦帳戶 (預設) 或服務登入帳戶與驗證使用 Azure 檔案儲存體的方式沒有任何差異。 您可以自行選擇如何在 AD 環境中，將儲存體帳戶表示為身分識別。 在 Join-AzStorageAccountForAuth 中設定的預設 DomainAccountType 是電腦帳戶。 不過，對於電腦或服務登入帳戶，AD 環境中設定的密碼到期日可能會有所不同，而且您必須在更新 AD 中您儲存體帳戶身分識別的密碼時將其納入考慮。

  • 如何在起始 Microsoft Entra ID 或 AD 認證的新連線之前，移除使用儲存體帳戶金鑰的快取認證並刪除現有的 SMB 連線？

    遵循下列兩個步驟程序來移除與儲存體帳戶金鑰相關聯的儲存認證，並移除 SMB 連線：

    1. 從 Windows 命令提示字元執行下列命令，以移除認證。 如果找不到認證，則表示您尚未保存認證，可以略過此步驟。

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. 刪除檔案共用的現有連線。 您可以將掛接路徑指定為掛接的磁碟機代號或 storage-account-name.file.core.windows.net 路徑。

      net use <drive-letter/share-path> /delete

  • 是否可能在檔案總管中檢視檔案/目錄擁有者的 userPrincipalName (UPN)，而非安全性識別碼 (SID)？

    檔案總管會直接對伺服器 (Azure 檔案儲存體) 呼叫 RPC API，以將 SID 轉譯為 UPN。 Azure 檔案儲存體不支持此 API，因此在檔案總管中，會顯示檔案/目錄擁有者的 SID，而非裝載於 Azure 檔案儲存體上的檔案和目錄 UPN。 不過，從加入網域的用戶端中，您可以使用下列 PowerShell 命令來檢視目錄中的所有項目及其擁有者，包括 UPN：

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

網路檔案系統 (NFS v4.1)

共用快照集

建立共用快照集

  • 我的共用快照集是否會異地備援？
    共用快照集擁有和目標 Azure 檔案共用相同的備援。 如果您為帳戶選取了異地備援儲存體，則共用快照集也會在配對區域中進行備援儲存。

清除共用快照集

  • 我是否可以刪除共用，而不刪除共用快照集？
    否。 刪除檔案共用工作流程會在您刪除共用時自動刪除快照集。

帳單和定價

  • Azure 檔案儲存體中有哪些交易，這些交易是如何計費的？每當使用者、應用程式、指令碼或服務與 Azure 檔案共享互動時，就會發生通訊協定交易 (寫入、讀取、列出、刪除檔案等)。 請務必記住，某些動作在您看來可能是單一作業，但實際上牽涉到多個交易。 對於以隨用隨付模型計費的標準 Azure 檔案共用，不同類型的交易會根據其對檔案共享的影響而有不同的價格。 交易不會影響進階檔案共用的計費，這些共用是使用佈建的模型進行計費的。 如需詳細資訊，請參閱瞭解計費。

  • 共用快照集需要多少成本？
    共用快照集具有累加性質。 基底共用快照集便是共用本身。 所有後續的共用快照集都是累加的，而且只會儲存與上一個共用快照集相異之處。 變更的內容才會計費。 如果您的共用有 100 GiB 資料，但在上一個共用快照集之後只變更了 5 GiB，則共用快照集只會再耗用 5 GiB，並以 105 GiB 來計費。 如需交易和標準輸出費用的詳細資訊，請參閱定價頁面。

與其他服務的互通性

  • 我可以使用 Azure 檔案共用作為 Windows Server 容錯移轉叢集的檔案共用見證嗎？
    Azure 檔案儲存體目前不支援此設定。 若要瞭解如何使用 Azure Blob 儲存體設定此功能，請參閱為容錯移轉叢集部署雲端見證。

另請參閱