DFS-R，如何在文件夾 ACL 不匹配的情況下重回正軌

DFS-R 配備 2 台伺服器。ServerA 在一個位置，ServerB 在另一個位置

從昨天早上開始，我們就處於不知道如何擺脫這種情況的境地。

情況：

我們接到一個電話，人們無法再訪問特定的 DFS 命名空間。環顧四周，我們發現在 ServerA 上，有人首先刪除了此文件夾上的共享，並且 2 不再存在 ACL。

第一步，在 DFS 命名空間上，我們禁用了 ServerA 上的文件夾目標。允許使用者訪問他們的文件。

複製看起來非常緩慢。drfsdiag backlog 在複製的兩側提供 101000+ 和 78000+ 文件。我猜可能是由於 ACL 不匹配。

使這種情況重回正軌的最佳方法是什麼？

• 停止將 ServerA 複製到 ServerB ？
• 刪除 ServerA 上的文件夾？
• 重新創建以 ServerB 作為主要來源的複制？
• 重新創建 ACL 並在 ServerA 上共享？
• 所有這些步驟都按特定順序？
• 等待積壓工作結束並繼續前進？

DFS-R 上真的很新，我們不知道如何繼續進行，以及所有可能的效果。

任何線索將不勝感激。

如果您更改了整個大型文件夾的 ACL，則必須等待積壓工作完成。對於類似情況，請參見此處和此處

如果這是不可接受的，您可以：

• 停止複制
• 刪除受影響的文件夾（僅在一側！）
• 用於robocopy預播現在空的目的地
• 重新啟用複制

但是，上述每個步驟都不是沒有停機時間，如果出現問題，您還可能使情況惡化。與往常一樣，先備份。

引用自：https://serverfault.com/questions/835700