Błąd przy uruchamianiu skryptu z UNC path

Błąd przy uruchamianiu skryptu ze ścieżki UNC oznacza, że interpreter (np. cmd.exe) domyślnie nie ustawia bieżącego katalogu na lokalizację sieciową — wymaga jawnego użycia `pushd` przed uruchomieniem skryptu.

Czym jest błąd przy uruchamianiu skryptu z UNC path

Błąd przy uruchamianiu skryptu z UNC path pojawia się wtedy, gdy skrypt zostaje wywołany bezpośrednio z lokalizacji zapisanej w formacie UNC, na przykład \\nazwa-komputera\udzial\skrypt.bat albo \\adres-serwera\katalog\zadanie.ps1. Taka ścieżka wskazuje zasób dostępny przez sieć, a nie folder znajdujący się na lokalnym dysku. System Windows może poprawnie odnaleźć sam plik, lecz jednocześnie nie potrafi ustawić bieżącego katalogu roboczego na lokalizację sieciową w taki sam sposób jak na dysku oznaczonym literą.

Problem dotyczy przede wszystkim sytuacji, w której zawartość skryptu odwołuje się do plików pomocniczych, programów lub katalogów względnymi ścieżkami. Przykładowo polecenie uruchamiające narzedzie.exe może działać po przeniesieniu skryptu na dysk lokalny, ale nie zadziałać po uruchomieniu go z udziału sieciowego. Interpreter poleceń, taki jak cmd.exe, wymaga wówczas dodatkowego wskazania lokalizacji roboczej albo zastosowania mechanizmu, który tymczasowo przypisze zasobowi sieciowemu literę dysku.

Nie jest to zwykle błąd samego kodu wykonywanego przez skrypt. Przyczyną bywa sposób, w jaki środowisko uruchomieniowe traktuje ścieżki UNC, uprawnienia do udziału, dostępność urządzenia w sieci lub różnice między uruchomieniem interaktywnym a wykonaniem zadania w tle.

Jak ścieżka UNC różni się od zwykłego katalogu

Typowa ścieżka lokalna ma postać C:\Skrypty\zadanie.bat. System może wtedy ustawić bieżący katalog roboczy na C:\Skrypty, a polecenia korzystające ze ścieżek względnych są rozwiązywane względem tego miejsca. Ścieżka UNC ma natomiast strukturę \\host\udział\katalog. Nie jest związana z literą dysku, dlatego nie wszystkie polecenia powłoki mogą traktować ją jako bieżący katalog w identyczny sposób.

W praktyce warto rozdzielić trzy elementy: położenie pliku skryptu, bieżący katalog procesu oraz prawa dostępu do zasobu. Sam fakt, że plik można otworzyć w Eksploratorze, nie oznacza jeszcze, że skrypt uruchomiony z wiersza poleceń będzie miał dostęp do wszystkich elementów udziału. Inne poświadczenia mogą być używane podczas pracy zalogowanego użytkownika, a inne przy uruchomieniu z harmonogramu zadań, usługi lub narzędzia administracyjnego.

Jednym ze standardowych sposobów obejścia ograniczenia jest użycie polecenia pushd. Przykładowa konstrukcja może wyglądać następująco:

pushd \\host\udzial\skrypty
call zadanie.bat
popd

pushd przechodzi do wskazanego zasobu i może utworzyć tymczasowe przypisanie litery dysku, dzięki czemu dalsze operacje otrzymują katalog roboczy akceptowany przez powłokę. Po zakończeniu pracy popd przywraca wcześniejszy stan. W przypadku skryptów PowerShell należy dodatkowo uwzględnić zasady wykonywania skryptów, sposób uwierzytelniania oraz to, czy dana sesja ma dostęp do udziału sieciowego.

Typowe problemy powodujące nieprawidłowe uruchomienie

Częstym objawem jest komunikat informujący, że bieżący katalog nie może być ustawiony na ścieżkę sieciową. Może pojawić się również informacja o braku dostępu, nieodnalezieniu pliku albo nierozpoznaniu polecenia, mimo że wskazany plik fizycznie znajduje się na udziale. W każdym przypadku warto najpierw ustalić, na którym etapie występuje problem.

• Brak jawnej zmiany katalogu — skrypt jest uruchamiany z UNC path, ale jego polecenia zakładają, że bieżące położenie zostało ustawione automatycznie.
• Ścieżki względne — odwołania takie jak .\dane lub ..\konfiguracja są rozwiązywane względem innego katalogu niż przewidziano.
• Nieprawidłowe cytowanie — spacje, znaki specjalne albo nawiasy w nazwie udziału mogą zmienić sposób interpretacji polecenia.
• Brak uprawnień — konto uruchamiające skrypt może nie mieć praw odczytu, zapisu lub wykonania na określonym zasobie.
• Różne środowisko uruchomieniowe — skrypt może działać ręcznie, lecz nie podczas uruchamiania przez Harmonogram zadań, ponieważ proces używa innego konta lub nie ma aktywnej sesji sieciowej.
• Niedostępny host albo udział — nazwa urządzenia może nie być rozpoznawana, połączenie może być zerwane, a zasób może zostać odłączony.
• Niewłaściwy interpreter — plik wsadowy, skrypt PowerShell i skrypt uruchamiany przez inne środowisko mogą wymagać odmiennych parametrów.

Pomocne jest sprawdzenie wartości zmiennej CD, użycie dir po wejściu do udziału oraz wyświetlenie pełnych ścieżek przekazywanych do kolejnych poleceń. Należy też zweryfikować, czy użycie call jest potrzebne przy wywoływaniu innego pliku wsadowego oraz czy polecenie kończące wcześniejszy etap nie zmienia katalogu roboczego.

Kiedy warto oddać urządzenie do diagnozy - Błąd przy uruchamianiu skryptu z UNC path

Do serwisu warto zgłosić się wtedy, gdy problem powtarza się mimo poprawnej składni, występuje tylko na jednym komputerze albo zależy od sposobu logowania użytkownika. Szczególnej uwagi wymagają przypadki, w których skrypt działa ręcznie, lecz nie uruchamia się z harmonogramu, po restarcie systemu lub po zmianie hasła do konta. W takich sytuacjach konieczne może być przeanalizowanie uprawnień, połączeń sieciowych, ustawień zapory, konfiguracji profilu użytkownika oraz parametrów procesu uruchamiającego zadanie.

Przydatne jest przekazanie pełnego komunikatu błędu, przykładowej ścieżki UNC bez poufnych danych, informacji o używanym interpreterze oraz wskazania, czy skrypt ma jedynie odczytywać pliki, czy również je tworzyć i modyfikować. Pozwala to odróżnić problem z katalogiem roboczym od błędu dostępu lub niedostępności udziału. W Warszawie takie przypadki można przekazać do punktu działającego jako Serwis laptopów i komputerów PC - Warszawa, gdzie analizie może zostać poddane zarówno środowisko systemu Windows, jak i sposób uruchamiania skryptu.

Nie zaleca się obchodzenia problemu przez trwałe mapowanie udziałów bez sprawdzenia, kto i w jakim trybie będzie korzystał z danego połączenia. Bezpieczniejsza konfiguracja powinna uwzględniać zakres wymaganych uprawnień, sposób przechowywania danych uwierzytelniających oraz zachowanie skryptu po utracie połączenia. Dzięki temu naprawa obejmuje nie tylko usunięcie pojedynczego komunikatu, lecz także ograniczenie ryzyka powrotu błędu przy kolejnych uruchomieniach.