Ĉu SMB-dosierujo ŝajnas malnova tra VPN? Kontrolu Senretajn dosierojn

Vi konektas la VPN, malfermas la mapitan diskon, kaj la dosierujo mankas dosieron, kiun la servilo evidente havas. La unua instinkto estas kulpigi la tunelon, la DNS aŭ la permesojn de Samba. En multaj kazoj la konekto estas en ordo kaj Esplorilo montras kaŝmemorigitan kopion de la kunhavo. Senretaj dosieroj povas liveri tiun kopion eĉ dum la VPN estas ŝaltita, ĉar la kunhavo, ne la tunelo, decidas ĉu la vido estas viva. La riparo komenciĝas per pruvo, kiun el la du vi rigardas.

La mito: VPN-ikono signifas, ke la kunhavo estas viva

La VPN-ikono raportas, ke tunelo ekzistas al la finpunkto. Ĝi diras nenion pri tio, ĉu aparta SMB-kunhavo estas atingebla, ĉu Esplorilo reŝaltis tiun kunhavon al interreta reĝimo, aŭ ĉu malsukcesa sinkronigo lasis pli malnovan kopion surloke. Ĝi ankaŭ ne diras al vi, kiun servilon elektis DFS-vojo.

Senretaj dosieroj konservas lokan kopion de alidirektitaj aŭ fiksitaj kunhavoj por ke ili restu disponeblaj kiam la servilo ne estas atingebla. Kiam la kunhavo revenas, la kliento devas reŝaltiĝi kaj sinkronigi. Politiko pri malrapida ligo povas decidi, ke la konekto ankoraŭ tro malrapidas kaj konservi la kaŝmemorigitan vidon, kaj pritraktata konflikto povas fari la samon eĉ sur rapida ligo.

Tial la simptomo ŝajnas selektema: unu dosierujo estas malnova, alia malfermiĝas ĝuste, kaj tria tute ne malfermiĝas. Tiuj estas tri malsamaj statoj, kaj nur la unua estas la kaŝmemora historio, pri kiu temas ĉi tiu artikolo. Nomu la staton antaŭ ol elekti riparon.

Pruvu, kiun celon Esplorilo legas

Komencu per la preciza UNC-vojo anstataŭ la disklitero. Mapita disko povas montri al alia kunhavo ol tiu, kiun vi pensas, kaj DFS-vojo povas rilati al tute alia servilo. Legado de la mapado montras la konservitan celon kaj ĝian staton:

Get-SmbMapping | Select-Object LocalPath, RemotePath, Status
Get-SmbConnection
net use

Malfermu la UNC-vojon rekte en nova fenestro de Esplorilo kaj komparu ĝin kun la mapita disko. Se la rekta vojo montras la aktualan dosieron kaj la mapita disko ne, la mapado estas parto de la problemo, ne la kaŝmemoro.

Poste kontrolu, ke la dosiero ekzistas por la celata uzanto. Administranta listo sur la servilo pruvas ekziston, ne tion, ke la ordinara SMB-uzanto havas la saman aliron, do kontrolu per la konto, kiu efektive uzas la kunhavon. Malsamaj akreditaĵoj produktas malsamajn vidojn pro kialoj tute senrilataj al kaŝmemoro. Ekzisto, aliro kaj videbleco estas tri apartaj kontroloj.

Legu la sinkronigan staton antaŭ ol forigi ion

La Sinkroniga Centro, kie la funkcio disponeblas, raportas ĉu la kunhavo laboras senrete, ĉu la lasta sinkronigo malsukcesis kaj ĉu konfliktoj atendas. Tiuj tri statoj kondukas al malsamaj riparoj, kaj forigo de la kaŝmemoro dum pritraktata konflikto povas perdi lokan laboron.

Serĉu lokajn ŝanĝojn, kiuj ne atingis la servilon, antaŭ ol malŝalti kaŝmemoradon, malfiksi la kunhavon aŭ forigi la senretan kopion. Dosiero, kiu ekzistas nur en la kaŝmemoro, ne estas malnova vido; ĝi estas nesinkronigita datumaro, kaj ĝi unue devas esti konservita per la aprobita procezo. Kaŝmemoro kun pritraktataj ŝanĝoj ne estas sekura forigi.

Post kiam la loka laboro estas sekura, uzu la subtenatan transiron al interreto kaj la sinkronigon, kaj poste denove komparu la liston. Malfermo de dua fenestro de Esplorilo ne devigas refreŝigon, ĉar ambaŭ fenestroj povas legi la saman lokan kaŝmemoron.

Riparu la staton de la kunhavo anstataŭ forigi la funkcion

Se la kunhavo restas senreta pro politiko pri malrapida ligo, adaptu la politikon por tiu kunhavo aŭ reto, anstataŭ malŝalti Senretajn dosierojn por ĉiuj uzantoj. Se la sinkronigo daŭre malsukcesas, ripari la malsukceson kaj solvu la konfliktojn; funkcianta sinkronigo estas tio, kio igas la kaŝmemorigitan kopion denove aktuala. Ŝanĝu la plej malgrandan politikon, kiu kovras la kunhavon. Tutmonda ŝanĝo interŝanĝas la malnovan vidon de unu uzanto kontraŭ la perdita senreta aliro de ĉiuj.

Por kunhavoj, kiuj neniam estu kaŝmemorigitaj, la servilo povas sendi konsilon por ĉiu kunhavo. Samba elmetas ĝin kiel kunhavan parametron, kaj la valoro por kunhavo, kiu devas resti nur interrete, estas:

csc policy = disable

Samba-parametra referenco difinas la permesitajn valorojn kaj ilian signifon. Apliku la agordon per la kunhava administrilo, kiu efektive generas la konfiguracion, precipe ĉe NAS, kaj memoru, ke la konsilo ne riparas datumojn jam kaŝmemorigitajn ĉe kliento.

Post iu ajn politika ŝanĝo, kontrolu, ke la kliento rekonektiĝas kaj ke la atendata dosiero aperas. Restartita servo ne estas pruvo, ke pritraktata loka ŝanĝo estis alŝutita, do kontrolu la dosieron, ne nur la konektan staton.

Kiam la kaŭzo ne estas Senretaj dosieroj

Se la UNC-vojo estas konfirmita interreta kaj freŝa listo ankoraŭ diferencas, la kaŝmemoro ne estas la klarigo. Kontrolu la permesojn de la kunhavo kaj de la dosiersistemo, la alirbazitan enumeracion kaj la servilon, kiun DFS-referenco efektive elektis. Ĉiu el tiuj povas kaŝi dosierujon sen iu loka kopio.

Kunhavo, kiu neniam konektiĝas, bezonas pruvojn pri enkursigado kaj servantaj filtriloj, ne kaŝmemoran kontrolon. Pordo 445 blokita tra la tunelo, DNS-nomo solvita al la malĝusta adreso aŭ fajroŝirma regulo, kiu permesas ping sed ne SMB, ĉiuj produktas malsukceson antaŭ ol la kaŝmemoro gravas.

La testo, kiu apartigas la du familiojn, estas simpla: dosierujo, kiu ekzistas sur la servilo, estas videbla al la ĝusta uzanto kaj ankoraŭ ne aperas interrete, indikas politikon aŭ enumeracion; dosierujo, kiu aperas kun malnova enhavo, indikas la kaŝmemoron. Diagnozu la familion antaŭ ol ŝanĝi agordon.