Udostępnianie plików


Tytulowe udostepnianie plików jest usluga, która realizuje ogromna wiekszosc serwerów Windows znajdujacych sie w sieci firmowej. Nawet, jezeli podstawowa rola serwera jest zupelnie inna, to pewnie i tak udostepnia pliki, co latwo wykaze wynik polecenia "net share". Wydawaloby sie, ze w przypadku udostepniania plików nie ma miejsca na wieksza filozofie, ale jak tak ostatnio sobie patrze, co wyczyniaja niektórzy administratorzy, to zaczynam sie zastanawiac, czy nie mam glowy za wysoko w chmurach i nie zakladam, ze wiedza jest tak oczywista, ze odruchowo zakladam, ze pewnych rzeczy nie da sie popsuc. Da sie, wiec na wszelki wypadek dzisiaj bedzie kilka nieskomplikowanych uwag na temat:

  • Udostepnianie plików realizowane jest przez systemowa usluge Server. Zatrzymanie tej uslugi sprawi, ze dane nie beda dostepne, co moze miec zarówno pozytywne jak i negatywne konsekwencje. Wewnetrznie, usluga Server nazywa sie LanmanServer i mozna ja "obejrzec" poleceniem sc.exe query LanmanServer.
  • Liste udzialów sieciowych mozna wyswietlic poleceniem "net share". Mozna tez zapytac przez WMI, uzywajac klasy Win32_Share w PowerShellu, WMIC albo w aplikacji.
  • Liste otwartych przez udzialy plików mozna wyswietlic poleceniem "net file". Polecenia tego mozna równiez uzyc do wymuszenia zamkniecia otwartego pliku, ale nalezy liczyc sie z tym, ze uzytkownik moze nie byc z tego powodu szczesliwy zwlaszcza, gdy utraci niezapisane dane.
  • Udostepnianie plików wykorzystuje protokól CIFS, który jest dialektem protokolu SMB. Dla chcacych pogrzebac w specyfikacji, Microsoft udostepnil odpowiednie zasoby. Protokól ten zostal na przestrzeni lat znaczaco usprawniony. Od czasów Windows Vista / Windows Server 2008 dziala naprawde wydajnie i nazywany jest SMB2.
  • Domyslnie, udostepniane sa wszystkie dyski (C$, D$...) i folder z systemem Windows (ADMIN$). Sa to specjalne udzialy z dostepem tylko dla administratorów. Technicznie mozliwe jest ich wylaczenie, jednak w wielu przypadkach moze to spowodowac klopoty z dzialaniem róznych narzedzi do zdalnego zarzadzania czy zdalnej instalacji.
  • Znak dolara ($) na koncu nazwy udzialu oznacza, ze serwer nie "chwali sie" takim udzialem w sieci. Udzial dziala normalnie, ale póki ktos nie wie jak sie nazywa, to go nie zobaczy. Przydaje sie to do porzadkowania widoków dla uzytkowników, jednak nie powinno byc traktowane jako skuteczne zabezpieczenie przed nieautoryzowanym dostepem.
  • Serwer plików publikuje swoje zasoby pod wlasna nazwa i pod swoim adresem IP. Zrobienie aliasu (na przyklad przez utworzenie rekordu CNAME w DNS) wcale nie sprawi, ze do serwera bedzie mozna siegnac w ten sposób. Zachowanie takie jest mozliwe do zmiany przy pomocy parametru DisableStrictNameChecking opisanego w KB281308.
  • Jezeli pliki udostepnia klaster, powyzsze ustawienie nie bedzie dzialac i dostep mozliwy jest tylko przez zarejestrowane w klastrze nazwy.
  • Jezeli ktos chce przeniesc cala strukture plików i udzialów na nowy serwer, moze uzyc narzedzia FSMT udostepnianego bezplatnie przez Microsoft.
  • Aby usluga Server "wiedziala" które foldery udostepnic i na jakich zasadach, siega do swojej bazy danych zapisanej w rejestrze, w kluczu Services\LanmanServer\Shares. Mozna ten klucz zapisywac i odtwarzac, jednak poza sciezkami zawiera on na przyklad dane o uprawnieniach i reczna edycja jego zawartosci jest ryzykowna.
  • Inne obecne w galezi Services\LanmanServer parametry opisane sa (choc dosc pobieznie i bardzo nieaktualnie) na stronach TechNet.
  • Na udziale mozna zalozyc ograniczenie liczby równoczesnych polaczen oraz ustawic prawa. Ustawianie praw na udzialach ma swoich zwolenników i przeciwników. Jezeli ktos nie ma bardzo silnych argumentów za taka konfiguracja, to mocno zachecam do zrezygnowania z ustawiania uprawnien na udziale i korzystania z uprawnien na plikach i folderach. Sa znacznie trudniejsze do przypadkowego ominiecia w codziennym sieciowym balaganie.
  • Uzywanie adresów IP zamiast nazw serwerów plików to proszenie sie o klopoty. Jezeli tylko DNS dziala poprawnie, uzycie nazw znaczaco uprosci przyszle zmiany. Jeszcze wieksza elastycznosc da zastosowanie DFS.
  • Serwer plików pozwala (przy pomocy wbudowanych mechanizmów audytu) na zapisywanie kto, kiedy, do czego i po co siegnal. Nalezy tylko zdawac sobie sprawe, ze nie pozostanie to bez wplywu na wydajnosc serwera. Domyslnie funkcjonalnosc ta jest wylaczona.
  • Nie da sie utworzyc udzialów o nazwie "pipe" ani "mailslot" . Wynika to z faktu, ze takimi nazwami usluga serwer posluguje sie przy specjalnych trybach komunikacji.
  • Udzialy na dyskach klastra traktowane sa w specjalny sposób, choc w nowszych systemach do zarzadzania nimi sluza te same API. Nie da sie jednak utworzyc udzialów na wolumenach CSV.

Podstawy? Oczywiscie! Ale nie kazdy sie rodzi z ich znajomoscia, wiec a nuz komus pomoga. Zwlaszcza, ze sa wakacje, wiec mozna siegnac po tematy troche lzejsze niz zwykle.

Autor: Grzegorz Tworek [MVP]

PS Jezeli ktos ma jakies sugestie pozwalajace na rozszerzenie mojej listy – prosze smialo w komentarzach. Poczytam, podyskutuje, pomysle i pewnie dodam dla tych, którzy jeszcze nie wszystko o udostepnianiu plików wiedza.

Comments (11)

  1. Anonymous says:

    FSMT nie wymaga DFSa. Choć oczywiście wie, że coś takiego istnieje i obsługuje poprawnie.

    Backup jest OK, jeżeli masz mało udziałów. Przy większej ilości samo ich odtworzenie na nowym serwerze staje się niemałą pracą, bo nie zawsze backup i restore klucza w rejestrze wystarcza.

  2. Anonymous says:

    Jako kontynuacje/rozwinięcie możesz opisać zasady prawidłowego udostępniania folderów w środowisku AD.

  3. Anonymous says:

    W sumie, to stwierdziłem, że będę miły i nie zacznę się nad nikim znęcać. Więc staram się opisać dobre praktyki i pozytywne strony zamiast wprost pisać co można popsuć. Każdy z nas kiedyś tego się uczył 🙂

  4. Anonymous says:

    @paweł: daje ci możliwość wyszukiwania przy pomocy narzędzi LDAP. nic poza tym.

    @GT: co do FSMT to lepszym narzędziem do migracji fileservera jest narzędzie do backupu. FSMT wymaga DFSa i tak na prawdę to się powinno nazywać DFS mig tool – czy coś przegapiłem? (:

  5. Anonymous says:

    @Bob: O! Nie wiedziałem tego. Sprawdzę w wolnej chwili i dopiszę do listy. Dziekuję! 🙂

  6. Grzegorzu poza tymi podstawowymi informacjami fajnie usłyszeć co nabrolili Ci "admini" 😉

  7. A tam, że dla kogoś oczywiste 😉 Czasem dobrze sobie coś takiego przeczytać i przypomnieć. Moim zdaniem bardzo dobry wpis.

  8. Bob Hyatt says:

    Jeżeli jest potrzeba aby serwer plików dostępny był pod kilkoma nazwami należy serwerowi dodać kolejną nazwę poprzez netdom computername

  9. pawel says:

    A proszę o wytłumaczenie, co mi daje opublikowanie udostępnionego zasobu w AD, od po prostu udostępnionego zasobu, bez publikacji w AD?

  10. Mirek Bielonka says:

    O właśnie dobre pytanie zadał Paweł. Ja też chętnie bym dowiedział się co mi daje publikacja udostępnionego zasobu w AD. Grzegorz, czy mógłbyś wyjaśnić? Dziękuję.

  11. pawel says:

    @nexor: dziękuję za wytłumaczenie.

Skip to main content