Harmonogram zadań nie widzi dysku sieciowego

Harmonogram zadań nie widzi dysku sieciowego wskazuje, że zadania systemowe uruchamiane przed pełnym zalogowaniem nie mają dostępu do zasobów zamapowanych w kontekście użytkownika.

Czym jest problem „Harmonogram zadań nie widzi dysku sieciowego”

Komunikat „Harmonogram zadań nie widzi dysku sieciowego” oznacza, że zadanie uruchamiane przez system Windows nie może skorzystać z zasobu dostępnego pod literą dysku, na przykład Y: albo W:. Taki dysk nie musi być uszkodzony ani odłączony. Często został wcześniej podłączony ręcznie w oknie Eksploratora plików, lecz jego dostęp obowiązuje wyłącznie w określonej sesji użytkownika. Harmonogram zadań może natomiast uruchamiać program w innym momencie, z innymi uprawnieniami i bez pełnego środowiska utworzonego podczas logowania.

Dysk sieciowy jest zwykle skrótem do lokalizacji zapisanej jako ścieżka UNC, na przykład \\nazwa-komputera\zasób. Litera przypisana do takiej lokalizacji ma charakter kontekstowy. Oznacza to, że może być widoczna w jednej sesji, ale niedostępna dla zadania uruchomionego jako inny użytkownik, przy starcie systemu albo z podwyższonymi uprawnieniami. W rezultacie skrypt, program do synchronizacji lub procedura wykonywania kopii zapasowej może zgłaszać brak pliku, pustą zawartość katalogu albo błąd dostępu, mimo że ręczne otwarcie tego samego dysku nadal działa.

Istotne jest rozróżnienie między niewidoczną literą dysku a rzeczywistym brakiem połączenia z lokalizacją. Jeżeli zadanie korzysta z Y:\dokumenty, a system nie odtworzył mapowania, ścieżka nie zostanie rozpoznana. Jeżeli natomiast zadanie używa bezpośrednio \\nazwa-komputera\zasób\dokumenty, problem może dotyczyć uwierzytelnienia, kolejności uruchamiania usług, dostępności połączenia albo praw do konkretnego katalogu.

Kontekst techniczny i porównanie sposobów dostępu - Harmonogram zadań nie widzi dysku sieciowego

Najczęstszą przyczyną różnicy między działaniem ręcznym a działaniem automatycznym jest odmienny kontekst uruchomienia. Po zalogowaniu użytkownik może mieć już aktywne poświadczenia, odtworzone mapowania i działające połączenie. Harmonogram zadań może jednak startować:

• przed zalogowaniem użytkownika,
• po zalogowaniu, ale z zaznaczoną opcją uruchamiania z najwyższymi uprawnieniami,
• na koncie innym niż to, które utworzyło mapowanie,
• bez aktywnej sesji pulpitu,
• z ograniczonym dostępem do poświadczeń zapisanych w profilu użytkownika.

W praktyce ścieżka z literą dysku jest mniej odporna na takie różnice niż pełna ścieżka UNC. Nie oznacza to jednak, że samo zastąpienie litery ścieżką UNC zawsze rozwiąże problem. Konto używane przez zadanie musi mieć prawo do odczytu lub zapisu, a lokalizacja musi być osiągalna w chwili uruchomienia operacji. Wymagane może być również jawne nawiązanie połączenia przed wykonaniem właściwego polecenia.

Znaczenie ma także ustawienie pola „Rozpocznij w” dla programu lub skryptu. Niektóre narzędzia poprawnie działają po uruchomieniu ręcznym, ponieważ korzystają wtedy z bieżącego katalogu użytkownika, lecz uruchomione przez harmonogram otrzymują inną lokalizację roboczą. Przy skryptach warto rozdzielić etap nawiązania dostępu od etapu przetwarzania plików, zapisać wynik do dziennika i sprawdzić kod zakończenia każdego polecenia.

Przy diagnozie należy porównać kilka elementów: konto przypisane do zadania, moment jego startu, dostępność połączenia, sposób wskazania zasobu, wymagane uprawnienia oraz to, czy hasło lub token dostępu nadal są ważne. Dopiero takie zestawienie pozwala ustalić, czy problem wynika z mapowania, autoryzacji, kolejności startu czy samego skryptu.

Typowe problemy i błędy prowadzące do braku dysku

Jednym z typowych błędów jest odwoływanie się w skrypcie do litery dysku, która została przypisana interaktywnie, ale nie jest dostępna w sesji zadania. Podobny efekt występuje po zmianie konta, zmianie hasła, odłączeniu i ponownym podłączeniu zasobu lub włączeniu opcji uruchamiania niezależnie od zalogowania. Wtedy Eksplorator może pokazywać lokalizację po zalogowaniu, natomiast harmonogram nadal otrzymuje komunikat o nieznanej ścieżce.

Problem może pojawić się również wtedy, gdy zadanie startuje zbyt wcześnie. Po uruchomieniu systemu interfejs użytkownika bywa już dostępny, ale karta sieciowa, połączenie bezprzewodowe albo odpowiednia usługa nie muszą być jeszcze gotowe. Zadanie wykonywane tylko raz może wtedy zakończyć się błędem, a późniejsza próba ręczna będzie poprawna. W takich przypadkach pomaga opóźnienie startu, warunek rozpoczęcia po uzyskaniu połączenia lub mechanizm ponawiania operacji.

Inną przyczyną są uprawnienia. Dostęp do samego udziału i dostęp do folderu na komputerze udostępniającym tworzą odrębne warstwy kontroli. Konto zadania może widzieć lokalizację, ale nie mieć prawa zapisu, usuwania albo odczytu wybranego pliku. Czasem zadanie działa z uprawnieniami administratora, a mapowanie utworzone w zwykłej sesji użytkownika pozostaje niewidoczne z powodu rozdzielenia środowisk uprawnień.

Do częstych błędów należą także:

• literówki w nazwie udziału lub katalogu,
• użycie starej nazwy komputera po zmianie konfiguracji,
• brak zapisanych albo wygasłych poświadczeń,
• uruchamianie programu bez wskazanego katalogu roboczego,
• brak obsługi błędu po nieudanej próbie połączenia,
• różnice między ścieżką używaną w Eksploratorze a ścieżką zapisaną w zadaniu,
• uruchamianie zadania w trybie, który nie pozwala na dostęp do zasobów wymagających interakcji użytkownika.

Przed zmianą konfiguracji warto sprawdzić historię zadania, dziennik aplikacji oraz dokładny kod błędu. Pomocne bywa także uruchomienie tego samego polecenia z konta przypisanego do zadania i zapisanie wyniku do lokalnego pliku diagnostycznego. Pozwala to odróżnić problem z widocznością dysku od błędu aplikacji, braku konkretnego pliku lub niewystarczających uprawnień.

Kiedy trzeba przekazać urządzenie do naprawy - Harmonogram zadań nie widzi dysku sieciowego

Do serwisu warto zgłosić problem, gdy zadanie wykonuje operacje na ważnych plikach, a próby naprawy powodują kolejne błędy uprawnień, znikające mapowania lub niepełne kopie danych. Szczególnej uwagi wymaga sytuacja, w której ręczne uruchomienie działa, lecz automatyczny proces regularnie pomija katalogi. Samo ponowne przypisanie litery dysku może wtedy tylko zamaskować przyczynę i nie zapewnić poprawnego działania po restarcie.

Podczas diagnostyki można przeanalizować ustawienia wyzwalacza, konto wykonujące zadanie, warunki sieciowe, ścieżki UNC, poświadczenia, prawa do odczytu i zapisu oraz zawartość dzienników. W razie potrzeby można również uporządkować skrypt tak, aby najpierw sprawdzał dostępność zasobu, następnie wykonywał operację, a na końcu zapisywał jednoznaczny rezultat. Takie podejście ułatwia późniejsze ustalenie, czy problem powrócił z powodu braku połączenia, zmiany hasła czy modyfikacji ustawień systemu.

W Warszawie wsparcie przy tego rodzaju usterkach zapewnia „Warszawskie Pogotowie Komputerowe 24/7”, gdzie można skorzystać z darmowej diagnozy LAPTOPA. Zgłoszenie jest uzasadnione zwłaszcza wtedy, gdy niedostępność dysku sieciowego wpływa na kopie zapasowe, automatyczną synchronizację albo codzienną pracę i nie da się jednoznacznie wskazać, czy źródłem jest harmonogram, konto użytkownika, połączenie czy konfiguracja samego zasobu.

Przed przekazaniem urządzenia lub zgłoszeniem zdalnego problemu warto przygotować opis oczekiwanego działania, nazwę zadania, informację o tym, czy błąd występuje przed logowaniem, oraz przykładową ścieżkę, do której program powinien uzyskać dostęp. Nie należy umieszczać w opisie haseł. Wystarczy wskazanie, czy połączenie jest nawiązywane ręcznie, czy ma być ustanawiane automatycznie przez zadanie.