Share niet toegankelijk

[nMzT94da]

Ik heb een gedeelde map gemaakt met backups van een laptop. Vervolgens heb ik met de beveiliging gespeeld. Zo heb ik zoveel mogelijk zaken aan gezet die het lastig maken de gegevens te benaderen, zo heb ik onder "Geavanceerd" alles aangevinkt, en niemand toegang verleend (behalve administrator het recht tot wijzigen rechten). Ik kon er niet meer in, en kon de rechten wel terugzetten. Daar heb ik het bij gelaten. Gisteren heb ik de Synology aangezet en een update uitgevoerd naar DSM 5.0 (welke versie ik had weet ik niet). Sindsdien is de schijf niet meer toegankelijk, maar tot overmaat van ramp de gebackupte laptop ook niet meer. Als ik de eingenschappen van de gedeelde map wil bewerken krijg ik uitgeschakelde tabbladen en velden te zien (zie schermafbeelding). Voor de bewuste map staat een slotje (zie schermafbeelding)

Ik wil mijn backup graag terug. Wat kan ik nog meer proberen behalve apparatuur om de harde schijf buiten het systeem uit te lezen?

[Babylonia]

Ik twijfel of het verstandig is geweest een share "System" te noemen?
Mogelijk zou die naam in gebruik kunnen zijn door de NAS zelf, in de niet getoonde systeem bestanden van de NAS?

Je kunt je NAS ook benaderen via WinSCP, om juist al die achterliggende mapjes op je NAS vanuit de root te benaderen die normaal niet zichtbaar of te benaderen zijn:
Zie < HIER >  Punt 1 t/m 10    (In jouw geval punt 8.1 niet vereist).

[nMzT94da]

De map staat niet meer in de lijst, alleen @system@ en daar staat niks in dat ik herken. Ook heb ik gecontroleerd dat verborgen mappen getoond werden. Ik denk dat ik als enige mogelijkheid een schijf er uit moet halen en middels ZAR of een vergelijkbaar recovery programma ga kijken wat ik kan redden.

Bedankt voor de hulp!

Ik twijfel of het verstandig is geweest een share "System" te noemen?
Mogelijk zou die naam in gebruik kunnen zijn door de NAS zelf, in de niet getoonde systeem bestanden van de NAS?

Je zou het in de eerste instantie wel denken, al ga ik er eigenlijk vanuit dat een consumentensysteem dit niet toe staat als het niet kan, en bij updates problemen oplost zodanig dat in ieder geval geen gegevens verloren gaan. Daarnaast ken ik zo snel geen systeem dat een "system" map in de root heeft.

En dan vraag ik me af waarom ze deze mappen in de root aanmaken, naast systeemmappen. Een enkele submap lost alle voorgenoemde problemen op.

[Babylonia]

De map staat niet meer in de lijst, alleen @system@ en daar staat niks in dat ik herken. Ook heb ik gecontroleerd dat verborgen mappen getoond werden.

Maar heb je dat nu gecontroleerd met WinSCP, of gewoon binnen de functies van DSM / File Station ?
File Station geeft niet de mappen en inhoud weer, die wel via WinCSP te bereiken zijn.

Voordat je een recovery doet, zou ik dat toch eerst proberen met WinSCP.

Overigens heb net even zelf gecontroleerd wat er aan mappen staat op de NAS via benadering met WinSCP.
"System" is inderdaad geen normale systeemmap, maar "Sys" wel. Overigens zijn er wel degelijk OS'sen met een "System" map. Bijv. het Portable "U3 systeem" wat bij bepaalde USB-disken gebruikt wordt.

Verder als je een share aanmaakt, zou ik voor alle zekerheid altijd een "prullenbak" instellen voor die share. Zodat per ongeluk weggegooide bestanden in de prullenbak terecht komen, en je die vanuit de prullenbak makkelijk weer terug kunt zetten.

[nMzT94da]

Via WinSCP gecontroleerd. Dankjewel voor je hulp.

De prullenbak staat inderdaad altijd aan; better safe then sorry! (alleen jammer dat het in dit geval toch mis ging)