Тека SMB виглядає застарілою через VPN? Перевірте автономні файли

Ви підключаєте VPN, відкриваєте зіставлений диск, і в теці немає файлу, який на сервері явно є. Перший порив — звинувачувати тунель, DNS або дозволи Samba. У багатьох випадках з'єднання гаразд, а Проводник показує кешовану копію спільної теки. Автономні файли можуть віддавати цю копію навіть при ввімкненому VPN, бо саме спільна тека, а не тунель, вирішує, чи актуальний вигляд. Виправлення починається з доказу того, на що саме ви дивитеся.

Міф: значок VPN означає, що спільна тека актуальна

Значок VPN повідомляє, що до кінцевої точки є тунель. Він нічого не каже про те, чи доступна конкретна спільна тека SMB, чи перевів Проводник її назад у режим онлайн і чи не залишила невдала синхронізація старішу копію. Він також не повідомляє, який сервер вибрав шлях DFS.

Автономні файли зберігають локальну копію перенаправлених або закріплених спільних тек щоб вони залишалися доступними, коли сервер недоступний. Коли тека повертається, клієнт має повернутися онлайн і синхронізуватися. Політика повільного з'єднання може вирішити, що зв'язок усе ще надто повільний, і зберегти кешований вигляд, а очікуваний конфлікт може зробити те саме навіть на швидкому каналі.

Тому симптом здається вибірковим: одна тека застаріла, друга відкривається правильно, а третя не відкривається взагалі. Це три різні стани, і лише перший — та історія з кешем, про яку ця стаття. Назвіть стан, перш ніж вибирати виправлення.

Доведіть, яку ціль читає Проводник

Почніть із точного шляху UNC, а не з літери диска. Зіставлений диск може вказувати на іншу спільну теку, ніж ви думаєте, а шлях DFS може стосуватися зовсім іншого сервера. Читання зіставлення показує збережену ціль і її стан:

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

Відкрийте шлях UNC безпосередньо в новому вікні Проводника й порівняйте його із зіставленим диском. Якщо прямий шлях показує поточний файл, а зіставлений диск ні, зіставлення — частина проблеми, а не кеш.

Потім переконайтеся, що файл існує для потрібного користувача. Список адміністратора на сервері доводить існування, а не те, що звичайний користувач SMB має той самий доступ, тому перевіряйте під обліковим записом, який справді використовує теку. Різні облікові дані дають різні вигляди з причин, не пов'язаних із кешем. Існування, доступ і видимість — три окремі перевірки.

Прочитайте стан синхронізації, перш ніж щось видаляти

Центр синхронізації, де ця функція доступна, повідомляє, чи тека працює автономно, чи остання синхронізація не вдалася і чи чекають конфлікти. Ці три стани ведуть до різних виправлень, а очищення кешу при очікуваному конфлікті може знищити локальну роботу.

Шукайте локальні зміни, що не дійшли до сервера, перш ніж вимкнути кешування, відкріпити теку або видалити автономну копію. Файл, що існує лише в кеші, — це не застарілий вигляд; це несинхронізовані дані, і їх спершу треба зберегти затвердженим процесом. Кеш з очікуваними змінами видаляти небезпечно.

Коли локальна робота в безпеці, скористайтеся підтримуваним переходом онлайн і синхронізацією, а потім знову порівняйте список. Відкриття другого вікна Проводника не примушує до оновлення, бо обидва вікна можуть читати той самий локальний кеш.

Виправте стан спільної теки, а не видаляйте функцію

Якщо тека залишається автономною через політику повільного з'єднання, налаштуйте політику для цієї теки або мережі, а не вимикайте автономні файли для всіх користувачів. Якщо синхронізація постійно не вдається, усуньте збій і розв'яжіть конфлікти; робоча синхронізація й робить кешовану копію знову актуальною. Змінюйте найменшу політику, що охоплює теку. Глобальна зміна міняє застарілий вигляд одного користувача на втрачений автономний доступ усіх.

Для спільних тек, які ніколи не мають кешуватися, сервер може надіслати підказку для кожної теки. Samba надає її як параметр спільної теки, а значення для теки, що має залишатися лише онлайн:

csc policy = disable

Довідник параметрів Samba визначає дозволені значення та їхнє значення. Застосовуйте налаштування через менеджер спільних тек, який справді створює конфігурацію, особливо на NAS, і пам'ятайте, що підказка не виправляє дані, вже кешовані на клієнті.

Після будь-якої зміни політики перевірте, що клієнт перепідключається і з'являється очікуваний файл. Перезапущена служба не доводить, що очікувану локальну зміну завантажено, тому перевіряйте файл, а не лише стан з'єднання.

Коли причина не в автономних файлах

Якщо шлях UNC підтверджено як онлайн, а свіжий список усе одно відрізняється, кеш не пояснення. Перевірте дозволи спільної теки й файлової системи, перелік на основі доступу та сервер, який фактично вибрав посилання DFS. Будь-що з цього може приховати теку без участі локальної копії.

Спільна тека, що ніколи не підключається, потребує доказів маршрутизації та фільтрації служб, а не перевірки кешу. Заблокований через тунель порт 445, ім'я DNS, що розв'язується в неправильну адресу, або правило брандмауера, яке дозволяє ping, але не SMB, дають збій ще до того, як кеш стане важливим.

Тест, що розділяє дві родини, простий: тека, яка є на сервері, видима потрібному користувачеві й усе ж не з'являється онлайн, указує на політику або перелік; тека, що з'являється зі старим вмістом, указує на кеш. Діагностуйте родину, перш ніж змінювати налаштування.