پوشه SMB از طریق VPN قدیمی به نظر می‌رسد؟ فایل‌های آفلاین را بررسی کنید
ممکن است Explorer در حالی که VPN متصل است، یک اشتراک کش‌شده را نشان دهد. پیش از غیرفعال کردن فایل‌های آفلاین، مسیر UNC، وضعیت همگام‌سازی و تغییرات در انتظار را مقایسه کنید.
به VPN متصل می‌شوید، درایو نگاشت‌شده را باز می‌کنید و در پوشه فایلی نیست که سرور آشکارا دارد. نخستین واکنش، متهم کردن تونل، DNS یا مجوزهای Samba است. در بسیاری از موارد اتصال سالم است و Explorer نسخه‌ای کش‌شده از اشتراک را نشان می‌دهد. فایل‌های آفلاین می‌توانند آن نسخه را حتی با روشن بودن VPN ارائه دهند، زیرا این اشتراک است، نه تونل، که تعیین می‌کند نما زنده است یا نه. اصلاح با اثبات این آغاز می‌شود که کدام یک را می‌بینید.
افسانه: نماد VPN یعنی اشتراک زنده است
نماد VPN گزارش می‌دهد که تونلی تا نقطه پایانی وجود دارد. این نماد چیزی درباره دسترسی‌پذیری یک اشتراک SMB مشخص نمی‌گوید، نه اینکه Explorer آن اشتراک را به حالت آنلاین برگردانده یا شکست همگام‌سازی نسخه قدیمی‌تری را سر جایش گذاشته است. همچنین نمی‌گوید کدام سرور را یک مسیر DFS انتخاب کرده است.
فایل‌های آفلاین نسخه محلی اشتراک‌های تغییرمسیرداده‌شده یا سنجاق‌شده را نگه می‌دارند تا زمانی که سرور در دسترس نیست، در دسترس بمانند. وقتی اشتراک برمی‌گردد، قرار است کلاینت به حالت آنلاین برگردد و همگام‌سازی کند. خط‌مشی پیوند کند ممکن است تصمیم بگیرد اتصال هنوز بیش از حد کند است و نمای کش‌شده را نگه دارد، و یک تعارض در انتظار می‌تواند حتی روی پیوند سریع همین کار را بکند.
به همین دلیل نشانه انتخابی به نظر می‌رسد: یک پوشه قدیمی است، دیگری درست باز می‌شود و سومی اصلاً باز نمی‌شود. این‌ها سه وضعیت متفاوت‌اند و تنها اولی همان داستان کشی است که این مقاله درباره آن است. پیش از انتخاب اصلاح، وضعیت را نام ببرید.
اثبات کنید Explorer کدام مقصد را می‌خواند
با مسیر دقیق UNC شروع کنید، نه با حرف درایو. یک درایو نگاشت‌شده ممکن است به اشتراکی متفاوت از آنچه فکر می‌کنید اشاره کند و یک مسیر DFS ممکن است به سروری کاملاً دیگر ارجاع دهد. خواندن نگاشت، مقصد ذخیره‌شده و وضعیت آن را نشان می‌دهد:
Get-SmbMapping | Select-Object LocalPath, RemotePath, Status
Get-SmbConnection
net useمسیر UNC را مستقیماً در پنجره جدید Explorer باز کنید و آن را با درایو نگاشت‌شده مقایسه کنید. اگر مسیر مستقیم فایل فعلی را نشان دهد و درایو نگاشت‌شده نشان ندهد، نگاشت بخشی از مشکل است، نه کش.
سپس تأیید کنید که فایل برای کاربر مورد نظر وجود دارد. فهرست مدیر روی سرور وجود را اثبات می‌کند، نه اینکه کاربر عادی SMB همان دسترسی را دارد، پس با حسابی که واقعاً از اشتراک استفاده می‌کند بررسی کنید. اعتبارنامه‌های متفاوت به دلایلی بی‌ربط با کش، نماهای متفاوتی تولید می‌کنند. وجود، دسترسی و دیدپذیری سه بررسی جداگانه‌اند.
پیش از پاک کردن هر چیزی، وضعیت همگام‌سازی را بخوانید
مرکز همگام‌سازی، در جایی که این ویژگی موجود است، گزارش می‌دهد که اشتراک آفلاین کار می‌کند یا نه، آخرین همگام‌سازی شکست خورده یا نه و آیا تعارض‌ها در انتظارند. این سه وضعیت به اصلاح‌های متفاوتی می‌رسند و پاک کردن کش در حالی که تعارضی در انتظار است می‌تواند کار محلی را از بین ببرد.
پیش از غیرفعال کردن کش، جدا کردن اشتراک یا حذف نسخه آفلاین، به دنبال تغییرات محلی بگردید که به سرور نرسیده‌اند. فایلی که فقط در کش وجود دارد نمای قدیمی نیست؛ داده همگام‌نشده است و نخست باید از طریق فرایند تأییدشده حفظ شود. کشی که تغییرات در انتظار دارد برای حذف ایمن نیست.
وقتی کار محلی ایمن شد، از گذار آنلاین و همگام‌سازی پشتیبانی‌شده استفاده کنید و سپس فهرست را دوباره مقایسه کنید. باز کردن پنجره دوم Explorer به‌روزرسانی را اجباری نمی‌کند، زیرا هر دو پنجره می‌توانند همان کش محلی را بخوانند.
وضعیت اشتراک را اصلاح کنید، نه اینکه ویژگی را حذف کنید
اگر اشتراک به دلیل خط‌مشی پیوند کند آفلاین می‌ماند، خط‌مشی را برای همان اشتراک یا شبکه تنظیم کنید، نه اینکه فایل‌های آفلاین را برای همه کاربران خاموش کنید. اگر همگام‌سازی مدام شکست می‌خورد، شکست را برطرف و تعارض‌ها را حل کنید؛ همگام‌سازی سالم چیزی است که نسخه کش‌شده را دوباره به‌روز می‌کند. کوچک‌ترین خط‌مشی‌ای را تغییر دهید که اشتراک را پوشش می‌دهد. تغییر سراسری نمای قدیمی یک کاربر را با از دست رفتن دسترسی آفلاین همه معاوضه می‌کند.
برای اشتراک‌هایی که هرگز نباید کش شوند، سرور می‌تواند یک راهنما برای هر اشتراک بفرستد. Samba آن را به‌عنوان پارامتر اشتراک ارائه می‌دهد و مقدار برای اشتراکی که باید فقط آنلاین بماند این است:
csc policy = disableمرجع پارامترهای Samba مقادیر مجاز و معنای آن‌ها را تعریف می‌کند. تنظیم را از طریق مدیر اشتراکی اعمال کنید که واقعاً پیکربندی را تولید می‌کند، به‌ویژه روی NAS، و یادتان باشد که راهنما داده‌هایی را که از قبل روی کلاینت کش شده‌اند اصلاح نمی‌کند.
پس از هر تغییر خط‌مشی، بررسی کنید که کلاینت دوباره متصل می‌شود و فایل مورد انتظار ظاهر می‌شود. سرویس راه‌اندازی‌شده مجدد اثبات آپلود شدن یک تغییر محلی در انتظار نیست، پس فایل را بررسی کنید، نه فقط وضعیت اتصال را.
وقتی علت فایل‌های آفلاین نیست
اگر مسیر UNC آنلاین تأیید شد و یک فهرست تازه هنوز متفاوت است، کش توضیح نیست. مجوزهای اشتراک و فایل‌سیستم، شمارش مبتنی بر دسترسی و سروری را که یک ارجاع DFS واقعاً انتخاب کرده بررسی کنید. هر یک از این‌ها می‌تواند پوشه‌ای را بدون دخالت هیچ نسخه محلی پنهان کند.
اشتراکی که هرگز متصل نمی‌شود به شواهد مسیریابی و فیلتر سرویس نیاز دارد، نه بررسی کش. پورت 445 مسدودشده در تونل، نام DNS که به آدرس اشتباه تبدیل می‌شود یا قاعده فایروالی که ping را مجاز می‌کند ولی SMB را نه، همگی پیش از اهمیت یافتن کش شکست ایجاد می‌کنند.
آزمونی که دو خانواده را جدا می‌کند ساده است: پوشه‌ای که روی سرور وجود دارد، برای کاربر درست قابل مشاهده است و هنوز آنلاین ظاهر نمی‌شود به خط‌مشی یا شمارش اشاره دارد؛ پوشه‌ای که با محتوای قدیمی ظاهر می‌شود به کش اشاره دارد. پیش از تغییر تنظیم، خانواده را تشخیص دهید.