How To

Sådan løser du fejlen “Det angivne netværksnavn er ikke længere tilgængeligt”

February 13, 2026 6 minutters læsning Updated: February 13, 2026

Det er ret irriterende at få fejlen ” Det angivne netværksnavn er ikke længere tilgængeligt “, især når du bare prøver at få adgang til delingsfiler, NAS-enheder, eller endda når serveren eller domænecontrolleren sender dette efter dig. Det er frustrerende, fordi det normalt peger på, at netværksressourcen ikke kan nås, men det kan også poppe op på grund af forkert konfigurerede protokoller eller sikkerhedsindstillinger, der blokerer vejen. Nogle gange er det bare serveren nede – hvilket du selvfølgelig ikke kan løse fra din side – men oftest er det noget på klientsiden eller en protokolfejl, der forårsager dette rod.

Denne guide præsenterer en håndfuld fejlfindingsruter. Nogle løsninger involverer at forsøge at få serveren til at fungere ordentligt igen, andre er nok til at justere din lokale maskine for at få forbindelse. Målet her er at få netværksressourcen tilgængelig uden at skulle vente på en administrator hver gang. Hvis du er på klientsiden, er mange af disse trin sikre at prøve på egen hånd, men hvis serveren er involveret, skal du have administratorrettigheder eller i det mindste en venlig systemadministrator til at udføre det hårde arbejde.

Hvordan retter man problemet med, at det angivne netværksnavn ikke længere er tilgængeligt?

Metode 1: Aktivér SMBv2/v3-protokollen

Lidt mærkeligt, men SMB-protokoller er ligesom rygraden i Windows-deling. Hvis SMBv2/3 ikke er aktiveret på hverken klienten eller serveren, ender du med denne fejl. SMBv1 er længe udfaset, så det er bedre at sikre sig, at SMBv2 eller v3 er aktiveret i begge ender.

På din maskine involverer dette at køre nogle kommandoer i en kommandoprompt med administratorrettigheder :

Tryk på Win + R, skriv cmd, og tryk derefter på Ctrl + Shift + Enterfor at åbne den som administrator.

Kør disse kommandoer:

sc config lanmanworkstation depend= bowser/mrxsmb20/nsi sc config mrxsmb20 start= auto

Genstart derefter. Ja, simpelt, men nogle gange er koldstart af Windows nødvendig for at ryste tingene løs. På nogle opsætninger var SMBv2 allerede aktiveret, men protokolafhængighederne var ødelagte – så nulstilling og genstart kan løse det.

Metode 2: Juster SMBv1-indstillinger om nødvendigt

I nogle tilfælde, især med ældre servere eller legacy-opsætninger, kan SMBv1 være involveret. Hvis SMBv1 er aktiveret på serveren, men din klient forsøger at bruge det, kan det forårsage fejlen, især hvis SMBv1 er deaktiveret eller blokeret på din maskine. Omvendt, hvis serveren kun understøtter SMBv1, men det er deaktiveret på din klient, er du i fare.

For at kontrollere og deaktivere SMBv1 på din side (fordi Windows selvfølgelig skal komplicere tingene), skal du køre en kommandoprompt med administratorrettigheder :

sc config lanmanworkstation depend= bowser/mrxsmb20/nsi sc config mrxsmb10 start= disabled

Eller, endnu bedre, kør kommandoen:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Fra PowerShell (kør som administrator).Husk blot, at hvis serveren kun understøtter SMBv1, skal du muligvis aktivere det på serveren. Det er en helt anden sag, men Microsoft har vejledninger til, hvordan man gør det sikkert – tænd det ikke bare blindt, især hvis det ikke er i brug andre steder – med sikkerhedsrisici og alt det der.

Metode 3: Sørg for, at firewallportene er åbne

Firewallblokering er en almindelig synder. Forskellige SMB-versioner kræver specifikke porte åbne for at kunne kommunikere korrekt. Så dobbelttjek dine Windows Firewall-regler (eller tredjeparts sikkerhedssoftware) og sørg for, at porte som 445 (TCP) er åbne. Nogle gange er porten blokeret for udgående eller indgående trafik, og det er nok til at forårsage fejlen.

For at gøre dette skal du køre wf.msc fra Kør, og derefter se under Indgående regler eller Udgående regler. Opret en ny regel for at tillade port 445 TCP (og UDP hvis nødvendigt).Hvis du er usikker, kan du slå de nøjagtige porte til din protokol op i Microsofts dokumentation. Normalt TCP 445er `n` nøglen til SMB.

Metode 4: Deaktiver eller konfigurer tredjeparts sikkerhedssoftware

Antivirus- eller netværksscannerværktøjer blokerer nogle gange SMB-trafik, især hvis de er overdrevent paranoide eller forkert konfigurerede. Prøv at deaktivere sikkerhedssoftwaren midlertidigt for at se, om det er årsagen. Hvis netværksressourcen bliver tilgængelig, ved du, at softwaren har mudret tingene.

Endnu bedre, tilføj netværksressourcen eller serveren til undtagelseslisten i din antivirus/firewall. Du behøver ikke at deaktivere den fuldstændigt, hvis du kan hvidliste den – vær bare forsigtig, og gør kun dette, hvis du har tillid til kilden.

Metode 5: Nulstil tilladelser på brugermappen for apps

Hvis dette problem opstår, når du bruger bestemte apps, især Unix-lignende undersystemer eller Docker, kan det være tilladelser relateret til AppData. Nogle gange bliver tilladelserne ødelagt, hvilket forhindrer apps i at få adgang til deres egne brugermapper og netværksressourcer.

Åbn en kommandoprompt med administratorrettigheder og kør:

icacls %USERPROFILE%\AppData /q /c /t /reset

Dette nulstiller tilladelser og forhåbentlig løser det de mærkeligste tilladelsesrelaterede fejl.

Metode 6: Dekomprimer eller afkrypter programmets brugermappe

Hvis appens brugermappe i AppData er komprimeret eller krypteret, kan det forårsage adgangsfejl. Dette er almindeligt, hvis du bruger diskkomprimerings- eller krypteringsværktøjer. For at løse dette skal du navigere til mappen, højreklikke, gå til Egenskaber og derefter under Avanceret fjerne markeringen i indstillingerne for Komprimer indhold for at spare diskplads og Krypter indhold for at sikre data. Dette burde give appen mulighed for at få normal adgang til sine filer.

Metode 7: Geninstaller programmet fuldstændigt

Nogle gange forårsager beskadigelse eller resterende indstillinger mærkelige netværksfejl. Afinstaller, ryd appens mappe i AppData\Local (og måske Packages, hvis det er en Microsoft-app), og geninstaller derefter på en frisk. Det rydder ofte op i den kryptiske tilstand, appen sad fast i.

Metode 8: Migrer fra FSR til DFSR for domænereplikering

Teknisk set kun relevant, hvis du promoverer en domænecontroller og støder på denne fejl under AD-opsætning eller -replikering.Ældre Windows Server-versioner bruger FRS (File Replication Service), som er forældet. Du skal migrere til DFSR (Distributed File System Replication).De officielle Microsoft-vejledninger er den bedste ressource til dette, f.eks.denne: Microsoft TechNet.

Metode 9: Dobbelttjek din brugerdefinerede kode

Hvis du skriver dine egne scripts eller apps, der tilgår netværksressourcer, kan fejlen ligge i din kode. Almindelige problemer omfatter forsøg på at skrive eller læse fra en stream, der allerede er lukket, eller at indstille en for kort timeout-periode. Nogle gange løser problemet blot at forlænge timeouts eller sikre, at din kode håndterer streamtilstande korrekt. Hvis du er i tvivl, kan du spørge i fora som StackOverflow.

Oversigt

Kontroller og aktiver SMB2/3-protokoller på klient og server.
Sørg for, at de nødvendige firewallporte (især 445 TCP) er åbne.
Deaktiver midlertidigt eller hvidliste sikkerhedssoftware.
Nulstil tilladelser på appmapper, hvis de virker ustabile.
Udpak eller afkrypter app-datamapper, hvis det kan forårsage problemer.
Geninstaller apps, hvis de opfører sig dårligt.
Overvej at migrere fra FRS til DFSR ved AD-relaterede fejl.
Gennemgå dine scripts eller programkode for almindelige fejl som lukkede streams eller lave timeouts.

Opsummering

Helt ærligt, fejlfinding af denne fejl kan føles som lidt af en skattejagt – nogle gange er det protokollen, nogle gange tilladelserne eller endda firewallen. At prøve disse løsninger peger dig normalt i den rigtige retning. På nogle maskiner kan en simpel genstart eller en hurtig protokoljustering rydde op i det hele. Det er ikke altid ligetil, men med tålmodighed er det overkommeligt. Forhåbentlig sparer det et par timer for nogen – det virker for mig, håber det også gør for dig.