Synology-Forum.nl
Hardware ondersteuning => Netwerk algemeen => Topic gestart door: watersource op 18 februari 2021, 14:43:03
-
Ik heb eerder een onderwerp gestart (https://www.synology-forum.nl/hardware-vragen/geen-verbinding-meer-met-ds418j-nas/msg295150/#msg295150) met de vraag hoe ik weer toegang kon krijgen tot mijn DS418j nas. Die toegang is inmiddels hersteld door het herplaatsen van de schijven in de nas en het herstarten van de nas.
Nu ben ik nog erg benieuwd waarom vorige week opeens, tijdens een bestandsoverdracht vanaf een pc (verbonden met kabel), de verbinding met de nas verloren is gegaan. Zijn er bijvoorbeeld logs die ik kan nakijken waarom de nas niet langer meer benaderbaar was?
Ik stel jullie tips zeer op prijs.
Bij voorbaat dank.
-
Zelfde antwoord als in je andere Topic (ik sluit die maar af): kijken in het Log Center.
-
Als je daar niets bijzonders kan ontdekken, dan zou je naar Hoofdmenu > Ondersteunings-center > Ondersteuningsservice kunnen gaan om een Logboek te genereren van System.
Er wordt dan een debug.dat gedownload naar je PC en dat is een zip file die je kunt uitpakken.
Na het uitpakken, ga je naar C:\DE DIRECTORY WAAR DE FILE IS UITGEPAKT\debug\dsm\var\log
Dan zou ik de files messages en dmesg openen in Notepad++ (of wat je zelf handiger vindt) en maar onderzoeken of er foutmeldingen zijn in de betreffende periode.
-
Dank voor je antwoord en het sluiten van het andere onderwerp :-).
Ik heb inmiddels in het log center gekeken maar hier zie ik alleen meldingen van er een succesvolle connectie is gemaakt tot 1 februari, daarna is eerste entry weer op 16 februari waarin gemeld wordt dat de nas weer succesvol gestart, gevolgd door waarschuwing dat er een start is na een 'improper shutdown'.
-
Als je daar niets bijzonders kan ontdekken, dan zou je naar Hoofdmenu > Ondersteunings-center > Ondersteuningsservice kunnen gaan om een Logboek te genereren van System.
Er wordt dan een debug.dat gedownload naar je PC en dat is een zip file die je kunt uitpakken.
Ik heb het vinkje aangezet voor Systeem voor het logboek wat gegenereerd dient te worden en druk op de knop om het logboek aan te maken. Ik krijg vervolgens een pop-up dat de download zo start en een progressbar die een aantal keren vol loopt. Daarna verdwijnt de progress bar weer zonder dat ik een browser heb gekregen om een bestand (lokaal?) te bewaren.
Waar kan ik de hierboven genoemde debug.dat file terug vinden zodat ik deze kan analyseren?
Alvast dank, mvg,
René
-
Dat ligt aan je instellingen van je Browser waar de download terecht komt..
Maar ik zie b.v. onderin in Chrome dat de download is gedaan en kan dan naar die locatie.
-
Dan zou ik de files messages en dmesg openen in Notepad++ (of wat je zelf handiger vindt) en maar onderzoeken of er foutmeldingen zijn in de betreffende periode.
Ik heb beide bestanden kunnen downloaden (geen idee waarom het op mijn reguliere pc niet lukte maar via een laptop lukte het wel om de bestanden op te slaan) en bekijken.
In het bestand dmesg staan alleen acties van gisteren (volgens mij het weer online komen van de nas maar hier kan ik mij in vergissen).
In het bestand messages staat veel meer, ook uit de tijd dat de nas niet meer te benaderen was.
Zie bijlage messages.txt het extract dat ik gemaakt heb, ik kon hier niet direct een fout uit herleiden waarom de nas niet langer benaderbaar was. Ik heb de specificieke namen en ip adressen weggehaald. het ip is mijn wan ip adres, de naam de ddyn van de nas.
Alvast dank voor je hulp.
Mvg.,
René
-
In het bestand dmesg staan alleen acties van gisteren (volgens mij het weer online komen van de nas maar hier kan ik mij in vergissen).
Ah...das waar, die file wordt regelmatig zipped, bijvoorbeeld dmesg.1.xz.
.xz is een zip file, die je dus kunt unzippen.
Kijk naar de datum die je nodig hebt.
Overigens is het handiger om grote output even in een .txt file te zetten en die toevoegen aan het Topic.
Heb je bericht aangepast.
-
ik kon hier niet direct een fout uit herleiden waarom de nas niet langer benaderbaar was.
Ik ook niet.
-
Ik vind het wel belachelijk weinig logregels per dag ;)
Maakt het wel overzichtelijker. Ik zie er ook geen fout in. ddns wodt dagelijks geüpdate, dus de internet verbinding is goed.
Ik zie wel een probleem met mail versturen? Gebruik je GMail? Eventueel moet je de GMail settings herbevestigen, vanwege een aanpassing van alweer een jaar geleden. Maar als de meldingen wel gewoon aankomen is dit een 'eenmalige' fout die gelogd wordt. Staat in elk geval los van het aanmelden.
-
Zie bijlage messages.txt het extract dat ik gemaakt heb, ik kon hier niet direct een fout uit herleiden waarom de nas niet langer benaderbaar was......
Dat textbestandje heb ik ook even bekeken, maar zie daarin toch duidelijk nogal wat foutmeldingen.
Teveel om op te noemen eigenlijk?
Request is missing required authentication credential ----> "status": "UNAUTHENTICATED"
Failed to send email
Failed to delete keys
Failed to process curl process
Failed to exec update access token command.
Of moet ik dit soort foutmeldingen dan zien, als "correct" - of heeft dat allemaal met mail te maken?
-
Die foutmeldingen hebben niets te maken met dit Topic.
Ik heb mij alleen gericht op het probleem.
-
Dan snap ik het het niet meer :o
Zijn dat dan willekeurige tekstbestandjes die de topic starter plaatst, wat niets met het probleem te maken heeft?
-
Nee, natuurlijk niet.
TS laat gewoon de log zien in de periode dat het netwerk weg viel, in de hoop dat de reden waarom te zien is.
Nou, die zag TS en ik niet.
Nu w88 op dmesg.
Topic gaat n.l. over "hoe achterhalen waarom netwerkverbinding verloren is gegaan" dus niet dat het verloren is gegaan, want dat wist TS al. ;)
-
Met wat ik zo denk te zien uit die meldingen probeert de topic starter via een DDNS-domein met zijn NAS contact te leggen?
Als om een of andere reden er een probleem ligt via die "omweg" connectie (via die DDNS-server), kun je er op die wijze dus niet in.
Gebruik binnen je thuis netwerk dan beter het LAN IP-adres van de NAS zelf.
Ben je niet afhankelijk van (tijdelijke) verbrekingen storingen extern.
Of de NAS een juiste connectie heeft met het LAN sub-net,
kun je terugzien in gegevens van aangesloten apparaten in de menu's van een router.
Of daar verbrekingen in zijn geweest, zou je dan mogelijk beter kunnen terugkijken in de loggegevens van de router.
-
Dank voor het in een txt bestand toevoegen, ik was me niet bewust dat dit een betere manier op dit forum is.
Deelde je mijn analyse dat er niet iets is te vinden wat het niet meer kunnen benaderen verklaart? Ik heb de andere bestanden proberen te unzippen, maar die waren allen van gisteren en de drie bestanden die ik had wilden niet uitpakken. Maar op basis van de bestanddatum denk ik dat er alleen informatie van gisteren in zit.
Is dan de eindconclusie dat de reden niet te achterhalen is of is er toch nog een andere manier om dit te analyseren?
Mijn dank is groot.
Mvg.,
René
-
Deelde je mijn analyse dat er niet iets is te vinden wat het niet meer kunnen benaderen verklaart?
Dat heb ik in reactie #8 aangegeven maar wel gericht op de vraag: "waarom netwerkverbinding verloren is gegaan".
denk ik dat er alleen informatie van gisteren in zit.
Nee, een bestaand dmesg.NR.xz wordt ook aangevuld, dus gewoon unzippen en kijken.
-
Met wat ik zo denk te zien uit die meldingen probeert de topic starter via een DDNS-domein met zijn NAS contact te leggen.
Als om een of andere reden er een probleem ligt via die "omweg" connectie (via die DDNS-server), kun je er op die wijze dus niet in.
Gebruik binnen je thuis netwerk dan beter het LAN IP-adres van de NAS zelf.
Ben je niet afhankelijk van (tijdelijke) verbrekingen storingen extern.
Of de NAS een juiste connectie heeft met het LAN sub-net,
kun je terugzien in gegevens van aangesloten apparaten in de menu's van een router.
Of daar verbrekingen in zijn geweest, zou je dan mogelijk beter kunnen terugkijken in de loggegevens van de router.
Hallo Babylonia, dank voor het meedenken. Ik heb zowel direct connect proberen te leggen als dat ik het via DDNS geprobeerd heb. Beide methodes waren jammer genoeg niet mogelijk in de periode tussen 30/1 en gistermorgen (toen ik de nas herstart had na het herplaatsen van de HDDs).
De nas was ook niet online te zien in de router, daar stond hij als een van de offline apparaten. Ik helaas in de app voor de router helaas geen loggegevens kunnen achterhalen over het wel of niet connectie verliezen van apparaten.
-
Nee, een bestaand dmesg.NR.xz wordt ook aangevuld, dus gewoon unzippen en kijken.
Ik heb het bestand dmesg.1.xz hernoemd naar dmesg.1.zip (en hetzelfde voor 2 en 3) maar krijg vervolgens de melding dat het geen geldig zip bestand is. Wat kan hiervoor de reden zijn?
-
Ik zie wel een probleem met mail versturen? Gebruik je GMail? Eventueel moet je de GMail settings herbevestigen, vanwege een aanpassing van alweer een jaar geleden. Maar als de meldingen wel gewoon aankomen is dit een 'eenmalige' fout die gelogd wordt. Staat in elk geval los van het aanmelden.
Dit is wellicht off-topic voor dit onderwerp, maar ik zag die foutmeldingen over de mail ook voorbij komen. Ik was me niet bewust van de noodzaak voor het herbevestigen van Gmail, maar op het moment dat ik Gmail als provider wil herbevestigen krijg ik een 404 melding en als ik de email instelling wil bewaren krijg ik de 401 error die ook in de log staat. Hoe kan ik hier het beste op acteren?
-
Ik heb het bestand dmesg.1.xz hernoemd naar dmesg.1.zip (en hetzelfde voor 2 en 3) maar krijg vervolgens de melding dat het geen geldig zip bestand is. Wat kan hiervoor de reden zijn?
Vraag me ook af of NAS logfiles wel ZIP-bestanden zijn? ---> men kan ze bijv. in een excel csv bestand wegschrijven / exporteren.
Mogelijke oplossing m.b.t. geen connectie met een NAS.
Herstarten van een NAS, is altijd een eerste actie om te proberen, als je er geen connectie mee kunt krijgen.
(Door bijv. een niet vast IP-adres, en mogelijk nog een lease van een oud IP-adres vanuit DHCP, kan men zoiets herstellen).
Wil je dat netjes herstarten (met een keurige afsluitprocedure), zonder te hoeven inloggen.
= paar seconden vasthouden van de powerknop, totdat je een piep hoort,
daarmee wordt een NAS netjes met een afsluitprocedure afgesloten en uitgezet.
Daarna weer opstarten. Krijgt een NAS een nieuwe IP-lease etc.
Vermeende netwerk problemen zijn erna meestal gecorrigeerd.
-
Ik weet alleen dat GMail de api aangepast heeft om toegang tot hun mail te krijgen. Synology heeft deze nieuw api ingebouwd en daardoor zijn de oude instellingen niet meer werkend. Mail moet je opnieuw instellen, maar herbevestigen was genoeg. Je krijgt dan geloof ik een nieuw activatie mailtje van Google waarin je bevestigd dat de nas een vertrouwd apparaat is. (Dit is nodig omdat die api de nas ook toegang tot je gmail adresboek geeft.)
Maar ik kan me alleen niet voorstellen dat je al een jaar niet merkt dat de meldingen niet werken. De fout kan ook iets anders zijn.
-
Daarna weer opstarten. Krijgt een NAS een nieuwe IP-lease etc.
Vermeende netwerk problemen zijn erna meestal gecorrigeerd.
Ja, maar dan weet je nog niet de oorzaak om dit in toekomst te vermijden. ;)
De .xz files zijn in een minder courant compressie formaat (Lempel–Ziv–Markov chain algorithm (https://en.wikipedia.org/wiki/Lempel–Ziv–Markov_chain_algorithm)). De default unzipper op de mac kan er ook niets mee. Ik gebruik het programma "The Unarchiver (https://theunarchiver.com)"
Het formaat wordt ook ondersteunt door het 7z programma (7-Zip) dat sinds een paar jaar op de nas staat. Via de commandline op de nas is het dan ook uit te pakken.
-
Ik heb ze idd altijd kunnen unzippen met 7-Zip.
-
Daarna weer opstarten. Krijgt een NAS een nieuwe IP-lease etc.
Vermeende netwerk problemen zijn erna meestal gecorrigeerd.
Ja, maar dan weet je nog niet de oorzaak om dit in toekomst te vermijden. ;)
Het formaat wordt ook ondersteunt door het 7z programma (7-Zip) dat sinds een paar jaar op de nas staat. Via de commandline op de nas is het dan ook uit te pakken.
Ik heb de bestanden met 7-zip uit kunnen pakken, in de drie bestanden gaan de logs terug tot 2014 (toen had ik deze nas nog niet, maar blijkbaar worden logs van de vorige nas meegenomen).
Jammer genoeg springt de log van 24 december 2020 naar 16 februari 2021, het moment dat de nas weer gereboot wordt. Daartussen is niet iets in de log te vinden. Als ik de log goed lees is 24 december ook een moment geweest dat de nas herstart werd, maar ik heb dit deel van de log apart bijgevoegd (van 24 dec 2020).
-
Even de puntjes op de i zetten, v.w.b. wanneer die gebeurtenis was:
Nu ben ik nog erg benieuwd waarom vorige week opeens, tijdens een bestandsoverdracht vanaf een pc (verbonden met kabel), de verbinding met de nas verloren is gegaan.
Dat was niet vorige week, maar op 2 februari, dus er moet gekeken worden naar die datum.
M.a.w. de messages file klopt niet, die is van januari (https://www.synology-forum.nl/hardware-vragen/geen-verbinding-meer-met-ds418j-nas/msg295150/#msg295150), kom ik net achter ::)
En aan de dmesg hebben we idd ook niet veel aan (dec 24 en feb 16).
Wat ik zou kunnen doen:
- Niet meer verder zoeken en het erbij laten.
- Of een Ticket inleggen, je verhaal doen en de debug.dat toevoegen.
-
Even de puntjes op de i zetten, v.w.b. wanneer die gebeurtenis was:
Nu ben ik nog erg benieuwd waarom vorige week opeens, tijdens een bestandsoverdracht vanaf een pc (verbonden met kabel), de verbinding met de nas verloren is gegaan.
Dat was niet vorige week, maar op 2 februari, dus er moet gekeken worden naar die datum.
Je hebt gelijk, de outage was niet vorige week op moment van schrijven maar al 31 januari. Vandaar ook de log die ik tot die datum had meegestuurd. De eerste log daarna was van 16 februari met het opstarten van de nas. Dit leek me niet relevant om mee te sturen.
En aan de dmesg hebben we idd ook niet veel aan (dec 24 en feb 16).
Duidelijk verhaal :).
Wat ik zou kunnen doen:
- Niet meer verder zoeken en het erbij laten.
- Of een Ticket inleggen, je verhaal doen en de debug.dat toevoegen.
Dank voor al je hulp hierbij. Jammer dat hier niet hier te vinden is, maar soms is het goed om die conclusie dan ook te trekken.