Megosztás a következőn keresztül:

Gyakori kérdések (GYIK) az Azure Filesról és az Azure File Syncről

  • Cikk

Az Azure Files teljes mértékben felügyelt fájlmegosztásokat kínál a felhőben, amelyek az iparági szabványnak megfelelő kiszolgálói üzenetblokk (SMB) protokoll és a hálózati fájlrendszer (NFS) protokollon keresztül érhetők el. Az Azure-fájlmegosztásokat egyidejűleg csatlakoztathatja a Windows, Linux és macOS felhőbeli vagy helyszíni üzemelő példányaihoz. Az Azure-fájlmegosztásokat a Windows Server-gépeken is gyorsítótárazhatja az Azure File Sync használatával, hogy gyorsan elérhesse az adatok felhasználási helyét.

Azure File Sync

  • Rendelkezhetek tartományhoz csatlakoztatott és nem tartományhoz csatlakoztatott kiszolgálókkal ugyanabban a szinkronizálási csoportban?
    Igen. A szinkronizálási csoportok olyan kiszolgálóvégpontokat tartalmazhatnak, amelyek eltérő Active Directory-tagsággal rendelkeznek, még akkor is, ha nem csatlakoznak tartományhoz. Bár ez a konfiguráció technikailag működik, ezt nem javasoljuk tipikus konfigurációként, mert előfordulhat, hogy az egyik kiszolgálón lévő fájlokhoz és mappákhoz definiált hozzáférés-vezérlési listákat (ACL-eket) a szinkronizálási csoport többi kiszolgálója nem tudja kikényszeríteni. A legjobb eredmény érdekében azt javasoljuk, hogy szinkronizálja azokat a kiszolgálókat, amelyek ugyanabban az Active Directory-erdőben találhatók, olyan kiszolgálók között, amelyek különböző Active Directory-erdőkben találhatók, de megbízhatósági kapcsolatokat létesítettek, vagy olyan kiszolgálók között, amelyek nem tartoznak tartományba. Javasoljuk, hogy kerülje a konfigurációk kombinációjának használatát.

  • Közvetlenül az Azure-fájlmegosztásomban hoztam létre egy fájlt az SMB használatával vagy a portálon. Mennyi ideig tart, amíg a fájl szinkronizálódik a szinkronizálási csoport kiszolgálóival?

    Az Azure-fájlmegosztáson az Azure Portal vagy SMB használatával végrehajtott módosításokat a rendszer nem észleli és replikálja azonnal, ellentétben a kiszolgálóvégponton elvégzett változtatásokkal. Az Azure Filesban még nincsenek módosítási értesítések, sem naplózás, így nincs lehetőség a szinkronizálási munkamenet automatikus kezdeményezésére a fájlok módosításakor. Windows Serveren az Azure File Sync Windows USN-naplózással indít automatikusan szinkronizálási munkamenetet a fájlok módosításakor.

    Az Azure-fájlmegosztás módosításainak észlelésére az Azure File Sync változásészlelési feladat nevű ütemezett feladata szolgál. A változásészlelési feladat számba veszi a fájlmegosztás összes fájlját, majd összeveti őket az adott fájl szinkronizált verziójával. Ha a változásészlelési feladat azt állapítja meg, hogy vannak módosított fájlok, az Azure File Sync elindít egy szinkronizálási munkamenetet. A változásészlelési feladat 24 óránként indul el. Mivel a változásészlelési feladat az Azure-fájlmegosztás összes fájlját számba veszi, a változásészlelés nagyobb névterekben tovább tart, mint kisebb névterekben. Nagy névterek esetében a 24 óránként egyszeri változásészlelésnél több időre lehet szükség a módosult fájlok azonosításához.

    Az Azure-fájlmegosztáson megváltozott fájlok azonnali szinkronizálásához használható aaz Invoke-AzStorageSyncChangeDetection PowerShell-parancsmag, amellyel manuálisan kezdeményezhető az Azure-fájlmegosztás változásainak észlelése. Ez a parancsmag olyan helyzetekhez készült, amikor valamilyen automatizált folyamat módosításokat végez az Azure-fájlmegosztásban, vagy a módosításokat egy rendszergazda hajtja végre (például fájlokat és könyvtárakat helyez át a megosztásba). Végfelhasználói módosítások esetén javasoljuk, hogy telepítse az Azure File Sync-ügynököt egy IaaS virtuális gépen, és hogy a végfelhasználók hozzáférjenek a fájlmegosztáshoz az IaaS virtuális gépen keresztül. Így az összes módosítás gyorsan szinkronizálódik más ügynökökkel az Invoke-AzStorageSyncChangeDetection parancsmag használata nélkül. További információkért tekintse meg az Invoke-AzStorageSyncChangeDetection dokumentációját.

    A Windows Serveren futó kötetekhez az USN-hez hasonló Azure-fájlmegosztások változásészlelési funkciójának hozzáadását vizsgáljuk. Az Azure Community Feedbackben való szavazással segíthet rangsorolni ezt a funkciót a jövőbeli fejlesztéshez.

  • Mi történik, ha ugyanazt a fájlt két kiszolgálón, körülbelül ugyanabban az időpontban módosítják?
    Fájlütközések akkor történnek, ha az Azure-fájlmegosztásban lévő fájl nem egyezik a kiszolgálóvégpont helyén található fájllal (eltér a méretük és/vagy a legutóbbi módosítás időpontja).

    A következő forgatókönyvek fájlütközéseket okozhatnak:

    • Létrehoztak vagy módosítottak egy fájlt egy végponton (például az A kiszolgálón). Ha ugyanezt a fájlt módosítják egy másik végponton, mielőtt végbemenne az A kiszolgáló szinkronizálása az adott végponttal, akkor a fájlok ütközni fognak.
    • A fájl a kiszolgálóvégpont létrehozása előtt már létezett az Azure-fájlmegosztásban és a kiszolgálóvégpont helyén. Ha a kiszolgálóvégpont létrehozásakor a kiszolgálón és az Azure-fájlmegosztásban lévő fájl fájlmérete és/vagy a legutóbbi módosításuk időpontja eltér, akkor a fájlok ütközni fognak.
    • Adatsérülés vagy a tudáskorlát elérése miatt újból létre lett hozva a szinkronizálási adatbázis. Az adatbázis újbóli létrehozása után a szinkronizálás úgynevezett egyeztetési módba lép. Ha az egyeztetéskor a kiszolgálón és az Azure-fájlmegosztásban lévő fájl fájlmérete és/vagy a legutóbbi módosításuk időpontja eltér, akkor a fájlok ütközni fognak.

    Miután a kezdeti feltöltés befejeződött az Azure-fájlmegosztásba, az Azure File Sync nem írja felül a szinkronizálási csoportban lévő fájlokat. Ehelyett egy egyszerű ütközésfeloldási stratégiát használ: a két végponton egyszerre módosított fájlok mindkét módosítását megtartja. A később végrehajtott módosítás tartja meg az eredeti fájlnevet. A régebbi fájl (amelyet a LastWriteTime határoz meg) a végpont neve és az ütközési szám hozzá van fűzve a fájl nevéhez. Kiszolgálóvégpontok esetében a végpont neve a kiszolgáló neve. Felhővégpontok esetén a végpont neve Felhő. A név a következő minta szerint épül fel:

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

    Például a CompanyReport.docx első ütköző fájljának új neve CompanyReport-CentralServer.docx lesz, ha a korábbi módosítás a CentralServer kiszolgálón lett végrehajtva. A második ütközés neve CompanyReport-CentralServer-1.docx lesz. Az Azure File Sync fájlonként 100 ütköző fájlt támogat. Ha az ütköző fájlok száma eléri a maximumot, a fájl szinkronizálása sikertelen lesz, amíg az ütköző fájlok száma 100 alá nem csökken.

  • Le van tiltva a felhőbeli rétegzés, miért vannak rétegzett fájlok a kiszolgáló végponthelyén?
    A rétegzett fájlok két okból létezhetnek a kiszolgáló végpontjának helyén:

    • Ha új kiszolgálóvégpontot ad hozzá egy meglévő szinkronizálási csoporthoz, ha a visszahívási névtér első vagy csak a visszahívási névtér lehetőséget választja a kezdeti letöltési módhoz, a fájlok rétegzettként jelennek meg, amíg helyileg le nem töltik őket. Ennek elkerülése érdekében válassza a rétegzett fájlok elkerülése lehetőséget a kezdeti letöltési módhoz. A fájlok manuális visszahívásához használja a Invoke-StorageSyncFileRecall parancsmagot.

    • Ha a felhőbeli rétegzés engedélyezve lett a kiszolgálóvégponton, majd le lett tiltva, a fájlok rétegzettek maradnak, amíg el nem érik őket.

  • Miért nem jelennek meg a rétegzett fájljaim miniatűrök vagy előnézetek a Windows Fájlkezelő?
    Rétegzett fájlok esetén a miniatűrök és az előnézetek nem láthatók a kiszolgálóvégponton. Ez azért várható, mert a Windows miniatűr-gyorsítótár funkciója szándékosan kihagyja a fájlok offline attribútummal való olvasását. Ha engedélyezve van a felhőbeli rétegzés, a rétegzett fájlok olvasása letöltést (visszahívást) okozna.

    Ez a viselkedés nem az Azure File Syncre jellemző. A Windows Fájlkezelő megjeleníti a "szürke X" karaktert az offline attribútumkészlettel rendelkező fájlokhoz. A fájlok SMB-en keresztüli elérésekor az X ikon jelenik meg. Ennek a viselkedésnek a részletes magyarázatáért tekintse meg a Miért nem kapok miniatűröket az offline jelölésű fájlokhoz?

    A rétegzett fájlok kezelésével kapcsolatos kérdésekért tekintse meg a rétegzett fájlok kezelését ismertető témakört.

  • Miért léteznek rétegzett fájlok a kiszolgálóvégpont névterén kívül?
    Az Azure File Sync ügynök 3-as verziója előtt az Azure File Sync letiltotta a rétegzett fájlok áthelyezését a kiszolgálóvégponton kívül, de a kiszolgálóvégponthoz hasonló köteten. A másolási műveletek, a nem rétegzett fájlok áthelyezése és a rétegzett fájlok áthelyezése más kötetekre nem volt hatással. Ennek a viselkedésnek az az implicit feltételezése volt, hogy Fájlkezelő és más Windows API-k áthelyezési műveletei ugyanazon a köteten (majdnem) azonnali átnevezési műveletek. Ez azt jelenti, hogy az áthelyezésekkel Fájlkezelő vagy más áthelyezési módszerek (például parancssor vagy PowerShell) nem válaszolnak, miközben az Azure File Sync visszahívja az adatokat a felhőből. Az Azure File Sync-ügynök 3.0.12.0-s verziójától kezdve az Azure File Sync lehetővé teszi egy rétegzett fájl áthelyezését a kiszolgálóvégponton kívülre. Elkerüljük a korábban említett negatív hatásokat, mivel lehetővé tesszük, hogy a rétegzett fájl rétegzett fájlként létezzenek a kiszolgálóvégponton kívül, majd visszahívjuk a fájlt a háttérben. Ez azt jelenti, hogy az áthelyezés ugyanazon a köteten azonnal megtörténik, és az áthelyezés befejezése után mindent megteszünk, hogy visszahívjuk a fájlt a lemezre.

  • Problémát tapasztalok az Azure File Sync szolgáltatással a kiszolgálón (szinkronizálás, felhőbeli rétegzés stb.). Távolítsam el és hozzam létre újra a kiszolgálóvégpontomat?

    Nem: a kiszolgálóvégpont eltávolítása nem olyan, mint a kiszolgáló újraindítása! A kiszolgálóvégpont eltávolítása és újrajavítása szinte soha nem megfelelő megoldás a szinkronizálással, a felhőbeli rétegzéssel vagy az Azure File Sync egyéb aspektusaival kapcsolatos problémák megoldásához. A kiszolgálóvégpont eltávolítása romboló művelet. Adatvesztést okozhat abban az esetben, ha a rétegzett fájlok a kiszolgálóvégpont névterén kívül léteznek. További információkért tekintse meg , hogy miért léteznek rétegzett fájlok a kiszolgáló végpontjának névterén kívül. Vagy elérhetetlen fájlokat eredményezhet a kiszolgálóvégpont névterében található rétegzett fájlokhoz. Ezek a problémák nem oldódnak meg a kiszolgálóvégpont ismételt létrehozásakor. A rétegzett fájlok akkor is létezhetnek a kiszolgálóvégpont névterében, ha soha nem engedélyezte a felhőbeli rétegzést. Ezért azt javasoljuk, hogy ne távolítsa el a kiszolgálóvégpontot, hacsak nem szeretné leállítani az Azure File Sync használatát ezzel a mappával, vagy egy Microsoft-mérnök kifejezetten erre utasította. További információ a kiszolgálóvégpontok eltávolításáról: Kiszolgálóvégpont eltávolítása.

  • Áthelyezhetem a társzinkronizálási szolgáltatást és/vagy tárfiókot egy másik erőforráscsoportba, előfizetésbe vagy Microsoft Entra-bérlőbe?
    Igen, áthelyezheti a társzinkronizálási szolgáltatást és/vagy tárfiókot egy másik erőforráscsoportba, előfizetésbe vagy Microsoft Entra-bérlőbe. A társzinkronizálási szolgáltatás vagy tárfiók áthelyezése után hozzáférést kell adnia a Microsoft.StorageSync alkalmazásnak a tárfiókhoz. Tegye a következők egyikét:

    1. Jelentkezzen be az Azure Portalra, és válassza a Hozzáférés-vezérlés (IAM) lehetőséget a szolgáltatás menüjében.

    2. A Szerepkör-hozzárendelések lapon listázhatja a tárfiókhoz hozzáféréssel rendelkező felhasználókat és alkalmazásokat (szolgáltatásnevek).

    3. Ellenőrizze, hogy a Microsoft.StorageSync vagy a Hybrid File Sync szolgáltatás (az alkalmazás korábbi neve) megjelenik-e a listában az Olvasó és adatelérés szerepkörrel.

      Ha a Microsoft.StorageSync vagy a Hibrid fájlszinkronizálási szolgáltatás nem jelenik meg a listában, hajtsa végre a következő lépéseket:

      • Válassza a Hozzáadás lehetőséget.
      • A Szerepkör mezőben válassza az Olvasó és adatelérés lehetőséget.
      • A Kiválasztás mezőbe írja be a Microsoft.StorageSync kifejezést, válassza ki a szerepkört, majd válassza a Mentés lehetőséget.

      Feljegyzés

      A felhővégpont létrehozásakor a társzinkronizálási szolgáltatásnak és a tárfióknak ugyanabban a Microsoft Entra-bérlőben kell lennie. A felhővégpont létrehozása után a társzinkronizálási szolgáltatás és a tárfiók áthelyezhető különböző Microsoft Entra-bérlőkbe.

  • Az Azure File Sync megőrzi a címtár-/fájlszintű NTFS ACL-eket az Azure Filesban tárolt adatokkal együtt?

    2020. február 24-étől az Azure-fájlszinkronizálás által rétegzett új és meglévő ACL-ek NTFS formátumban maradnak, és a közvetlenül az Azure-fájlmegosztáson végrehajtott ACL-módosítások szinkronizálódnak a szinkronizálási csoport összes kiszolgálójára. Az Azure-fájlmegosztásokon végzett ACL-módosítások az Azure File Syncen keresztül szinkronizálódnak. Amikor adatokat másol az Azure Filesba, győződjön meg arról, hogy olyan másolási eszközt használ, amely támogatja a szükséges "hűséget" attribútumok, időbélyegek és ACL-ek Azure-fájlmegosztásba való másolásához – akár SMB-en, akár REST-en keresztül. Az Azure-beli másolási eszközök, például az AzCopy használatakor fontos, hogy a legújabb verziót használja. A fájlmásolási eszközök táblázatában áttekintheti az Azure másolási eszközeit, így meggyőződhet arról, hogy a fájl összes fontos metaadatait átmásolhatja.

    Ha engedélyezte az Azure Backupot az Azure File Sync által felügyelt fájlmegosztásokon, a fájl ACL-ek továbbra is visszaállíthatók a biztonsági mentés visszaállítási munkafolyamatának részeként. Ez a teljes megosztásra vagy az egyes fájlokra/könyvtárakra is használható.

    Ha pillanatképeket használ az Azure File Sync által felügyelt fájlmegosztások ön által felügyelt biztonsági mentési megoldásának részeként, előfordulhat, hogy az ACL-ek nem lesznek megfelelően visszaállítva NTFS ACL-re, ha a pillanatképek 2020. február 24-e előtt készültek. Ha ez történik, vegye fel a kapcsolatot az Azure ügyfélszolgálatával.

  • Szinkronizálja az Azure File Sync a Könyvtárak LastWriteTime-ját? Miért nem frissül egy könyvtár módosított időbélyege a benne lévő fájlok módosításakor?
    Nem, az Azure File Sync nem szinkronizálja a könyvtárak LastWriteTime-ját. Ezenkívül az Azure Files nem frissíti a címtárak módosított időbélyegét (LastWriteTime) a címtárban lévő fájlok módosításakor. Ez az elvárt működés.

  • Miért hívja vissza a rétegzett fájlokat az AFS-kiszolgálón található vírusirtó szoftver?
    Amikor a felhasználók hozzáférnek a rétegzett fájlokhoz, bizonyos vírusirtó (AV) szoftverek nem szándékos fájlvisszahívásokat okozhatnak. Ez akkor fordul elő, ha az AV-szoftver nincs úgy konfigurálva, hogy figyelmen kívül hagyja a rétegzett fájlokat (a RECALL_ON_DATA_ACCESS attribútummal rendelkezőket). A következő történik:

    1. A felhasználó megkísérli elérni a rétegzett fájlokat.
    2. Az AV szoftver blokkolja az olvasási leírót.
    3. Az AV-alkalmazás ezután saját olvasást végez a fájl víruskereséséhez.

    Ez a folyamat úgy tűnhet, mintha az AV-szoftver visszahívja a rétegzett fájlokat, de valójában a felhasználó hozzáférési kísérlete aktiválja. A probléma elkerülése érdekében győződjön meg arról, hogy az AV-szállító úgy konfigurálja a szoftverét, hogy figyelmen kívül hagyja a rétegzett fájlokat a RECALL_ON_DATA_ACCESS attribútummal.

  • Blokkolhatja az SSL-ellenőrző szoftver az AFS-kiszolgálókhoz való hozzáférést? Győződjön meg arról, hogy az SSL-ellenőrző szoftver (például a Zscaler vagy a FortiGate) lehetővé teszi az Azure File Sync (AFS) kiszolgálóvégpontok elérését az Azure-hoz. Ezek az SSL-ellenőrző eszközök felülbírálhatják a tűzfal beállításait, és szelektíven engedélyezhetik a forgalmat. A probléma megoldásához forduljon a hálózati rendszergazdához. A "testnet" paranccsal állapítsa meg, hogy az AFS-kiszolgáló tapasztalja-e ezt a problémát.

Biztonság, hitelesítés és hozzáférés-vezérlés

  • Hogyan naplózhatom a fájlhozzáférést és a módosításokat az Azure Filesban?

    Az Azure Files naplózási funkcióját két lehetőség közül választhatja:

    • Ha a felhasználók közvetlenül férnek hozzá az Azure-fájlmegosztáshoz, az Azure Storage-naplók segítségével nyomon követheti a fájlmódosításokat és a felhasználók hozzáférését hibaelhárítási célokra. A kérések naplózása a legjobb munkamennyiség alapján történik.
    • Ha a felhasználók olyan Windows Serveren keresztül férnek hozzá az Azure-fájlmegosztáshoz, amelyen telepítve van az Azure File Sync-ügynök, egy naplózási szabályzattal vagy külső termékkel követhetik nyomon a fájlmódosításokat és a felhasználói hozzáférést a Windows Serveren.

  • Támogatja az Azure Files az Access-alapú enumerálást (ABE) az SMB Azure-fájlmegosztásokban lévő fájlok és mappák láthatóságának szabályozásához?

    Az ABE Használata az Azure Files szolgáltatással jelenleg nem támogatott, de az DFS-N SMB Azure-fájlmegosztásokkal is használható.

  • Menthetek egy Azure-fájlmegosztásba nyomtatóval vagy szkennerrel?

    Az Azure Files csak a Windows, a Linux és a macOS rendszert támogatja. Az Azure-fájlmegosztások közvetlenül nyomtatóról vagy szkennerről való elérése nem támogatott. Ha azonban már használja az Azure File Syncet, kinyomtathatja vagy átvizsgálhatja a Windows-fájlkiszolgálót, majd szinkronizálhatja a fájlt egy Azure-fájlmegosztással.

Identitásalapú hitelesítés

  • Támogatja a Microsoft Entra Domain Services az SMB-hozzáférést a Microsoft Entra hitelesítő adataival a Microsoft Entra-azonosítóhoz csatlakoztatott vagy regisztrált eszközökről?

    Nem, ez a forgatókönyv nem támogatott.

  • Használhatom a canonical name (CNAME) nevet egy Azure-fájlmegosztás csatlakoztatásához identitásalapú hitelesítés használata közben?

    Igen, ez a forgatókönyv mostantól SMB Azure-fájlmegosztások esetén is támogatott egyerdős és többerdős környezetekben. Az Azure Files azonban csak tartományi előtagként támogatja a CNAM-ek konfigurálását a tárfiók neve alapján. Ha nem szeretné előtagként használni a tárfiók nevét, fontolja meg inkább az elosztott fájlrendszerbeli névterek használatát.

  • Hozzáférhetek a Microsoft Entra hitelesítő adataival rendelkező Azure-fájlmegosztásokhoz egy másik előfizetésben lévő virtuális gépről?

    Ha a fájlmegosztást üzembe helyező előfizetés ugyanazzal a Microsoft Entra-bérlővel van társítva, mint az a Microsoft Entra Domain Services-telepítés, amelyhez a virtuális gép tartományhoz csatlakozik, akkor az Azure-fájlmegosztásokhoz ugyanazzal a Microsoft Entra-hitelesítő adatokkal férhet hozzá. A korlátozás nem az előfizetésre, hanem a társított Microsoft Entra-bérlőre vonatkozik.

  • Engedélyezhetem a Microsoft Entra Domain Servicest vagy a helyszíni AD DS-hitelesítést az Azure-fájlmegosztásokhoz egy Olyan Microsoft Entra-bérlő használatával, amely eltér az Azure-fájlmegosztás elsődleges bérlőétől?

    Szám Az Azure Files csak a Microsoft Entra Domain Services szolgáltatást támogatja, vagy a helyszíni AD DS-integrációt egy Olyan Microsoft Entra-bérlővel, amely ugyanabban az előfizetésben található, mint a fájlmegosztás. Az előfizetések csak egy Microsoft Entra-bérlőhöz társíthatók. Ha helyszíni AD DS-t használ hitelesítéshez, az AD DS hitelesítő adatait szinkronizálni kell azzal a Microsoft Entra-azonosítóval , amelyhez a tárfiók társítva van.

  • Támogatja az Azure-fájlmegosztások helyszíni AD DS-hitelesítése egy több erdőt használó AD DS-környezettel való integrációt?

    Az Azure Files helyszíni AD DS-hitelesítése csak annak a tartományi szolgáltatásnak az erdőjével integrálható, amelyen a tárfiók regisztrálva van. Egy másik erdő hitelesítésének támogatásához a környezetnek megfelelően kell konfigurálnia egy erdőmegbízhatóságot. Részletes útmutatásért lásd: Az Azure Files használata több Active Directory-erdővel.

    Feljegyzés

    Többerdős telepítés esetén ne használja a Fájlkezelő a Windows ACL-ek/NTFS-engedélyek gyökér-, könyvtár- vagy fájlszinten való konfigurálásához. Használjon inkább icacls-eket .

  • Van különbség abban, hogy számítógépfiókot vagy szolgáltatás-bejelentkezési fiókot hoz létre, hogy a tárfiókomat képviselje az AD-ben?

    A számítógépfiók (alapértelmezett) vagy a szolgáltatás-bejelentkezési fiók létrehozása nem különbözik attól, hogy a hitelesítés hogyan működik az Azure Files használatával. A tárfiókok identitásként való ábrázolására az AD-környezetben saját maga dönthet. A parancsmagban Join-AzStorageAccountForAuth beállított alapértelmezett DomainAccountType a számítógépfiók. Az AD-környezetben konfigurált jelszó lejárati ideje azonban eltérő lehet a számítógép- vagy szolgáltatás-bejelentkezési fiókok esetében, és ezt figyelembe kell vennie ahhoz, hogy frissítse a tárfiók identitásának jelszavát az AD-ben.

  • Hogyan távolítható el a gyorsítótárazott hitelesítő adatok tárfiók-kulccsal és a meglévő SMB-kapcsolatok törlése a Microsoft Entra-azonosítóval vagy az AD-hitelesítő adatokkal való új kapcsolat inicializálása előtt?

    Az alábbi két lépésben távolítsa el a tárfiókkulcshoz társított mentett hitelesítő adatokat, és távolítsa el az SMB-kapcsolatot:

    1. Futtassa a következő parancsot egy Windows parancssorból a hitelesítő adatok eltávolításához. Ha nem talál egyet, az azt jelenti, hogy nem őrizte meg a hitelesítő adatokat, és kihagyhatja ezt a lépést.

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

    2. Törölje a fájlmegosztás meglévő kapcsolatát. A csatlakoztatási útvonalat a csatlakoztatott meghajtóbetűjelként vagy az storage-account-name.file.core.windows.net elérési útként is megadhatja.

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

  • Meg lehet tekinteni egy fájl/könyvtár tulajdonosának userPrincipalName (UPN) értékét a biztonsági azonosító (SID) helyett a Fájlkezelő?

    Fájlkezelő közvetlenül a kiszolgálóra (Azure Files) hívja meg az RPC API-t, hogy lefordítsa a SID-et egy UPN-re. Az Azure Files nem támogatja ezt az API-t, ezért Fájlkezelő egy fájl/könyvtár tulajdonosának SID-címe jelenik meg az Azure Filesban tárolt fájlok és könyvtárak UPN-je helyett. Tartományhoz csatlakoztatott ügyfélről azonban a következő PowerShell-paranccsal megtekintheti a címtárban lévő összes elemet és azok tulajdonosát, beleértve az UPN-et is:

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

Hálózati fájlrendszer (NFS v4.1)

Pillanatképek megosztása

Megosztási pillanatképek létrehozása

  • A megosztási pillanatképek georedundánsak?
    A megosztási pillanatképek redundanciájával ugyanaz a redundancia áll rendelkezésre, mint az Azure-fájlmegosztás, amelyhez készítették őket. Ha a fiókjához georedundáns tárolást választott, a megosztás pillanatképe is redundánsan lesz tárolva a párosított régióban.

Megosztási pillanatképek törlése

  • Törölhetem a megosztásomat, de nem törölhetem a megosztás pillanatképeit?
    Szám A fájlmegosztás törlési munkafolyamata automatikusan törli a pillanatképeket a megosztás törlésekor.

Számlázás és árképzés

  • Mik az Azure Files tranzakciói, és hogyan történik a számlázásuk? A protokolltranzakciók akkor fordulnak elő, amikor egy felhasználó, alkalmazás, szkript vagy szolgáltatás együttműködik az Azure-fájlmegosztásokkal (fájlok írása, olvasása, listázása, törlése stb.). Fontos megjegyezni, hogy egyes műveletek, amelyeket egyetlen műveletnek tekinthet, valójában több tranzakciót is magukban foglalhatnak. A használatalapú fizetéses modellen számlázott standard Azure-fájlmegosztások esetében a különböző típusú tranzakciók ára eltérő a fájlmegosztásra gyakorolt hatásuk alapján. A tranzakciók nem befolyásolják a kiépített modellel számlázott prémium fájlmegosztások számlázását. További információ: A számlázás ismertetése.

  • Mennyibe kerül a pillanatképek megosztása?
    A megosztási pillanatképek növekményes jellegűek. Az alapmegosztás pillanatképe maga a megosztás. Minden későbbi megosztási pillanatkép növekményes, és csak az előző megosztási pillanatkép különbségét tárolja. Csak a módosított tartalomért kell fizetnie. Ha 100 GiB-adattal rendelkezik megosztással, de a legutóbbi megosztási pillanatkép óta csak 5 GiB változott meg, a megosztási pillanatkép csak 5 további GiB-t használ fel, és 105 GiB-ért kell fizetnie. A tranzakcióval és a szokásos kimenő díjakkal kapcsolatos további információkért tekintse meg a Díjszabás oldalt.

Együttműködés más szolgáltatásokkal

  • Használhatom az Azure-fájlmegosztásomat fájlmegosztási tanúsítóként a Windows Server feladatátvevő fürthöz?
    Ez a konfiguráció jelenleg nem támogatott az Azure Files esetében. Ha szeretné megtudni, hogyan állíthatja be ezt az Azure Blob Storage használatával, olvassa el a Felhőtanúsító üzembe helyezése feladatátvevő fürthöz című témakört.

Lásd még