FW 4.0.2, verschwundene Standard-Freigaben

  • Hallo zusammen,


    ich betreibe schon eine ganze weile eine TS210 mit 2*1TB und gefühlt auch seit ca. 4 Wochen die aktuelle FW 4.0.2, bis gestern problemlos.


    Gestern morgen jedoch waren kein Zugriffe mehr auf die eingerichteten Freigaben möglich. Die Status-LED blinkt abwechselnd rot/grün, was laut Doku bei einer schon länger eingerichteten Box nicht unbedingt zum Standard-Verhalten gehört und kein gutes Zeichen ist. Browser-Interface und, glücklicherweise, auch SSH-Zugriff auf die Box funktioniert noch.


    Also zunächst einmal ein wenig im Browser-Interface gestöbert. Die Freigabe-Ordner sind noch vorhanden. Aber halt, drei der Ordner werden mit identischem Namen doppelt angezeigt. Auch im Browser-Filemanager tauchen diese doppelt auf. Die Navigation verhält sich hier etwas konfus, da es sich hier tatsächlich um jeweils zweimal den gleichen Ordner handelt. Aber zumindest die Daten sind noch alle vorhanden. Die Schreib/Lese-Berechtigungen der Benutzer scheinen jedoch auch eher zufällig verteilt als der ursprünglichen Konfiguration zu entsprechen.


    In den System-Benachrichtigungen finde ich etwas von einem "unclean shutdown" tags zuvor. Das würde zwar das rot/grüne blinken der Status-LED erklären, da in einem solchen Fall das Raid neu gesynct wird, aber eine Erklärung für den "unclean shutdown" habe ich spontan nicht. Die Box legt sich per Timer um 23:00 von alleine schlafen, einen Stromausfall gab's zwischenzeitlich nicht.


    Im Web-Interface ist beim Speichermanagement nur "aktualisieren" zu lesen mit einem relativ langsam voranschreitenden, prozentualen Fortschritt. Deswegen einmal via SSH mit der Box verbunden. Ein "cat /proc/mdstat" fördert zutage, das sich das Raid tatsächlich am synchronisieren ist. Erwartete Zeit ca. 4 Stunden :schnarch: . Also lieber erst mal abwarten.


    Nach ca. 4 Stunden ist's dann soweit.


    Code
    [~] # cat /proc/mdstatPersonalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4]md0 : active raid1 sdb3[1] sda3[0]      1951945600 blocks [2/2] [UU]md2 : active raid1 sdb2[1] sda2[0]      530048 blocks [2/2] [UU]md13 : active raid1 sdb4[1] sda4[0]      458880 blocks [2/2] [UU]      bitmap: 0/57 pages [0KB], 4KB chunkmd9 : active raid1 sda1[0] sdb1[1]      530048 blocks [2/2] [UU]      bitmap: 0/65 pages [0KB], 4KB chunkunused devices: <none>


    Sync ist fertig, Zugriff auf die Shares immer noch nicht möglich und die besagten doppelten Ordner immer noch doppelt. Versuchsweise mal einen Reboot, hilft aber nicht. Die Symptome bleiben die gleichen. SSH wieder angeschmissen.


    Code
    [~] # ps | grep smb22662 admin       564 R   grep smb


    Siehe da, der smb läuft gar nicht. Mal manuell nachhelfen: "/etc/init.d/smb.sh start". Sieht nach normalem Startverhalten aus, aber "ps | grep smb" sagt immer noch nein. Da gibt's doch bestimmt Logfiles.


    Code
    [~] # cat /var/log/log.smbd[2013/10/15 18:09:19,  0] smbd/server.c:1330(main)  smbd version 3.5.2 started.  Copyright Andrew Tridgell and the Samba Team 1992-2010[2013/10/15 18:09:19.930374,  0] passdb/pdb_interface.c:259(guest_user_info)  guest_user_info: Unable to locate guest account [nobody]![2013/10/15 18:09:19.930740,  0] smbd/server.c:1474(main)  ERROR: failed to setup guest info.


    Aha, zumidest Fehlermeldungen im Log. An dieser Stelle einmal Freund Google bemüht und auf diesen Link gestoßen. Ist schon etwas älter, aber es werden die gleichen Symptome beschrieben. Bevor ich, wie im Beitrag vorgeschlagen, die smb-default-Konfiguration verwende, schau ich mir mal die aktuelle an.


    Code
    [~] # cat /etc/smb.conf "guest"read list = "user2"write list = "admin","user1"valid users = "root","user2","admin","user1"inherit permissions = yesrecycle bin = yes[WSUS]comment =path = /share/MD0_DATA/WSUSbrowsable = yesoplocks = yesftp write only = nopublic = yesinvalid users = "guest"read list = "user2"write list = "admin","user1"valid users = "root","user2","admin","user1"inherit permissions = yesrecycle bin = yes[projects]comment =path = /share/MD0_DATA/projectsbrowsable = yesoplocks = yesftp write only = nopublic = yesinvalid users =read list = "guest"write list = "admin","user1","user2"valid users = "root","user2","admin","user1","guest"inherit permissions = yesrecycle bin = yes[shared]comment =path = /share/MD0_DATA/sharedbrowsable = yesoplocks = yesftp write only = nopublic = yesinvalid users =read list =write list = "admin",@"everyone","guest"valid users = "root","admin",@"everyone","guest"inherit permissions = yesrecycle bin = yes[WSUS]comment =path = /share/MD0_DATA/WSUSbrowsable = yesoplocks = yesftp write only = nopublic = yesinvalid users = "guest"read list = "user2"write list = "admin","user1"valid users = "root","user2","admin","user1"inherit permissions = yesrecycle bin = yes[projects]comment =path = /share/MD0_DATA/projectsbrowsable = yesoplocks = yesftp write only = nopublic = yesinvalid users =read list = "guest"write list = "admin","user1","user2"valid users = "root","user2","admin","user1","guest"inherit permissions = yesrecycle bin = yes[shared]comment =path = /share/MD0_DATA/sharedbrowsable = yesoplocks = yesftp write only = nopublic = yesinvalid users =read list =write list = "admin",@"everyone","guest"valid users = "root","admin",@"everyone","guest"inherit permissions = yesrecycle bin = yes[Qmultimedia]comment = System default sharepath = /share/MD0_DATA/Qmultimediabrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = guestread list = @"everyone"write list = adminvalid users = root,@"everyone",admininherit permissions = yes[Qdownload]comment = System default sharepath = /share/MD0_DATA/Qdownloadbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = guestread list =write list = adminvalid users = root,admininherit permissions = yes[Qrecordings]comment = System default sharepath = /share/MD0_DATA/Qrecordingsbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = guestread list =write list = adminvalid users = root,admininherit permissions = yes[Qweb]comment = System default sharepath = /share/MD0_DATA/Qwebbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = guestread list =write list = adminvalid users = root,admininherit permissions = yes[Qusb]comment = System default sharepath = /share/MD0_DATA/Qusbbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = guestread list =write list = adminvalid users = root,admininherit permissions = yes[Public]comment = System default sharepath = /share/MD0_DATA/Publicbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = guestread list = @"everyone"write list = adminvalid users = root,@"everyone",admininherit permissions = yes[homes]comment = System default sharepath = /share/MD0_DATA/homesbrowsable = yesoplocks = noftp write only = norecycle bin = norecycle bin administrators only = nopublic = yesinvalid users =read list =write list = adminvalid users = root,admininherit permissions = yes[global]socket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=65536 SO_RCVBUF=65536null passwords = yesuse sendfile = yesoplocks = yesdeadtime = 10username level = 0display charset = UTF8unix extensions = nostore dos attributes = yesclient ntlmv2 auth = yesdos filetime resolution = noinherit acls = yeswide links = yesforce unknown acl user = yestemplate homedir = /share/homes/DOMAIN=%D/%Udomain logons = nomin receivefile size = 4096case sensitive = autopreferred master = nodomain master = autolocal master = noos level = 20map archive = nomap system = nomap hidden = nomap read only = noveto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/.@__qini/.Qsync/.upload_cache/.qsync/.qsync_sn/passdb backend = smbpasswdenhance acl v1 = yesremove everyone = nokernel oplocks = nomangled names = noprintcap cache time = 0workgroup = WORKGROUPsecurity = USERserver string = QNAP Fileserverhost msdfs = no[home]comment = Homepath = %Hbrowsable = yesoplocks = yesftp write only = noinherit permissions = yesinvalid users = guestwritable = yesread list = "%u"write list = "%u"valid users = "%u"root preexec = /sbin/create_home -u '%q'[Qsync]comment = Qsyncpath = /share/Qsyncbrowsable = yesoplocks = yesftp write only = noinherit permissions = yeswritable = yeswrite list =read list = "%u"valid users = "%u"vfs objects =


    Offensichtlich fehlt am Anfang der smb.conf schon ein wenig. Dafür sind die Sektionen [WSUS], [projects] und [shared] gleich doppelt vorhanden. Das erklärt zumindest die doppelt vorhandenen Verzeichnisse bei der Ordner-Freigabe-Konfiguration und im File-Browser. Ansonsten sind alle zuvor einmal konfigurierten Freigaben vorhanden.


    Dann mal die smb.conf aus dem Verzeichnis "/etc/default_config" übernehmen. Die besteht nur aus einer [global]-Sektion. Ein vorheriger Vergleich mit der aktuell vorhandenen [global]-Sektion zeigt nicht viele Gemeinsamkeiten. Was soll's, nicht funktionieren tut's jetzt auch schon.


    Code
    [~] # cp /etc/config/smb.conf /etc/config/smb.conf.FAILED
    [~] # cp -f /etc/default_config/smb.conf /etc/config/smb.conf
    [~] # /etc/init.d/smb.sh start
    locks path was set to /share/MD0_DATA/.locks
    Starting winbindd services:Starting SMB services:.
    [~] # ps | grep smb
    29391 admin      3260 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
    29398 admin      1284 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
    29555 admin       568 R   grep smb
    [~] #


    Alte Konfiguration vorher mal sichern, Default-Konfiguration kopieren und smbd manuell starten. Startverhalten sieht genau so aus wie zuvor, aber: der smbd läuft schon mal.


    Dann im zuvor gefundenen Beitrag weiter: Standard-Freigaben wieder herstellen. Im Browser-Interface sind keine Freigaben mehr vorhanden. Logisch, in der default-"smb.conf" waren ja auch keine drin. Der Klick auf den Button "Standard-Freigabeordner wieder herstellen" führt aber nur zu einer Fehlermeldung "Standardfreigaben" sind schon vorhanden?! Schade.


    Packen wir halt die Freigaben aus der fehlerhaften smb.conf dazu, die doppelten Einträge lassen wir weg und starten den smbd einmal neu. Siehe da, die Ordner-Freigaben sind wieder da und Zugriff über Netz geht auch wieder. Lesen funktioniert auf Anhieb, die Schreibberechtigungen bei den Standardfreigaben fehlen teilweise. Im Browser-Interface entsprechend korrigiert, erst einmal wieder ok.


    Was noch bei dieser Odyssee aufgefallen ist, ich mir aber nur zu 99% sicher bin: die Benutzer-Eigenen-Ordner, welche bisher unter "/share/MD0_DATA/[Benutzername]/" lagen, sind jetzt unter "/share/MD0_DATA/homes/[Benutzername]/" zu finden. Der Name für die Freigabe des Benutzerordners unter Windows lautet allgemein "//QNAP/home". Die "smb.conf"gibt das auch so her und finde ich eigeintlich auch ok. Aber die Daten lagen, nach wie vor, im alten Verzeichnis, die neuen Verzeichnisse waren noch leer. Kann man ja rüberkopieren. Bin mir aber eben zu 99% sicher, das bis zu diesem Ereignis der Zugriff auf das Home-Verzeichnis noch auf dem alten Speicherort erfolgte.


    Wurde dieses Verhalten mit "unclean shutdown" und zerschossener "smb.conf" und verschobenen "home"-Verzeichnissen schon einmal beobachtet? Liegt's an der Firmware-Version?

  • Hallo zusammen,


    da ich im Rahmen des oben beschriebenen Ereignisses wegen verschiedener Kleinigkeiten noch ein paar Nachforschungen angestellt habe sei noch folgendes ergänzt:


    Das Runterfahren per Timer um 23:00 Uhr wird normalerweise brav im Systemlog vermerkt. Am Abend zuvor war dies jedoch nicht der Fall. Die TS war am folgenden Morgen jedoch definitiv aus. Aber ein paar Stunden vor ihrer Schlafenszeit war im Log vermerkt "[Mirror Disk Volume: Drive 1 2] Drive 2 removed". Da hat sich also bei laufender TS eine Platte vermeintlich abgemeldet. Die Platte wurde dann am Folgetag beim Einschalten wieder als "added into Volume" erkannt. Das erklärt zumindest den "unclean shutdown" und das darauf folgende syncen. Der SMART-Zustand dieser Platte ist auch nicht "gut", sondern nur "normal". In den SMART-Details tauchen ein paar Read-Errors auf. Wahrscheinlich liegt da eine Platte im sterben.


    Nun zu den Eingangs erwähnten Kleinigkeiten:
    Nachdem der smbd mit default-[global]-conf--Sektion wieder zum Leben erweckt wurde, taucht die TS in der Windows-Netzwerkumgebung (Win7Pro64) nur noch sporadisch auf. Ansprechbar sind die Freigaben unter ihrem bekannten Namen aber immer. In der zerschossenen smb.conf war "os level = 32" eingetragen, in der default.smb.conf nur "os level = 20". Änderung auf 32 brachte hier keine Besserung. Hat jemand eine Ahnung, woran das "nicht-Auftauchen" in der Netzwerkumgebung sonst noch liegen könnte?


    Wenn ich mit meinem Android-Tablet auf die TS zugreife, wird neuerdings dann auch die Freigabe "IPC$" angezeigt. Dies war voher nicht der Fall. (Android Filemanager ist ES Explorer). Beim Zugriff mit Windows-Rechnern auf die TS wird diese administrative Freigabe natürlich nicht angezeigt. Woran liegt das?


    Im Standard-Freigabe-Ordner "Qmultimedia" wird seitdem auch das Verzeichnis ".hccache" angezeigt. Ich vermute, das dieses Verzeichnis zur Multimedia-Sation gehört und schon immer da war. Nur angezeigt wurde es bisher nicht. Woran liegt das?


    Bin für Inspirationen aller Art dankbar.


    Gruß,
    McPan

  • Hallo zusammen,


    kleines Statusupdate: Festplatte(n) wegen unmotivierten Abmeldens und Lesefehlern beim Plattentest ausgetauscht. In diesem Zusammenhang dann FW 4.0.2 "from scratch" installiert, die TS ist damit wieder jungfräulich. Nach nächtlicher Kopieraktion der Daten von der noch intakten Platte auf das neue Raid via RTRR ist die TS wieder einsatztbereit.


    Die stille Hoffnung, dass sich die im Thread zuvor erwähnten "Kleinigkeiten" damit von alleine erledigen, hat sich leider nicht bestätigt. Lediglich die benutzerspezifischen Ordner mit dem Namen \\QNAP\[Benutzername] sind wieder vorhanden. Zusätzlich ist für jeden Benutzer noch jeweils das Verzeichnis \\QNAP\home vorhanden. Dieses sind aber unterschiedliche Verzeichnisse und werden nicht auf den gleichen Ordner gemappt. Na ja.


    Die Anzeige der TS in der Win7-Netzwerkumgebung ließ sich durch anlegen der Datei "/etc/lmhosts" mit dem Inhalt "[QNAP-IP-Adresse] QNAP#20" bewerkstelligen. Eintrag "os level = 20" in der "/etc/config/smb.conf" auf dieser Voreinstellung belassen.


    Gruß,
    McPan

  • Hallo McPan,



    deine Ausführungen beschreiben ein ähnliches Problem bei mir. Leider bin ich in Sachen SSH und Linux-Befehle eine Null. Vielleicht ist mir aber doch zu helfen ;).



    Rahmenbedingungen:
    QNAP Support: Hilft nicht weiter. Ließt nicht mal die Problemstellung und schickt nur vorgefertigste, nichtssagende Textbausteine :(
    System: QNAP TS-419P II
    Firmeware: 4.0.2
    Festplatte: 4 gleiche Seagate 2 TB im RAID 5


    Mein Problem, ALLE Shared-Ordner sind weg, nicht nur die standardmäigen. Wiederherstellen lassen sie sich auch nicht mit der gleichen Fehlermeldung wie bei dir. Problem, ich muss an ein paar Daten davon ran, also nicht alles löschen. Da alles Ordner weg sind (der Speicher auf der Platte auch aber noch als belegt gekennzeichnet wird) komme ich weder per AFP, noch per FTP an irgend welche Daten. Time Machine funktioniert auch nicht. Scheint die selbe Ursache zu haben.


    Wie kann ich die Ordner wiederbeleben? :oops: Ich hoffe Du kannst mir helfen :thumb:


    Die besten Grüße,
    DeGe

  • Hallo DeGe,


    auch wenn ich keine TS-419 und auch kein RAID5, sondern "nur" RAID1 habe könnte ich mir vorstellen, dass wir bei gleicher Firmware ähnliche Voraussetzungen haben. Möglicherweise sind, bei anscheinend gleichen Symptomen auch die gleichen Abhilfemaßnahmen erfolgreich. Die Ursache für meine "zerschossene" smb.conf ist mir zwar trotz der Gewissheit, eine laut SMART-Daten nicht mehr so ganz dolle Platte im Raid gehabt zu haben, nicht so ganz klar, aber vielleicht lässt sich deine Station zumindest für die nötige Datenrückgewinnung erst einmal wiederbeleben.


    Sofern du noch Zugriff auf die Web-Oberfläche der TS hast, ist Hopfen und Malz wahrscheinlich noch nicht verloren.


    Dass der Dienst für Windows-Freigaben im Netzwerk auf der TS auch tatsächlich aktivier ist setzte ich jetzt mal als gegeben voraus, siehe QNAP-Oberfläche->Systemsyterung->Netzwerkdienst->Win/MAC/NFS->Reiter "Microsoft Netzwerk"->Haken bei "Dateidienst für Microsoft Netzwerke aktivieren".


    Auf der TS-Adminstrations-Web-Seite gibt's zwar unter "QNAP-Oberfläche->Systemsteuerung->Systemeinstellung->Verwaltung->Reiter "Systemservice" unter dem Eintrag "Microsoft Netzwerk" die grüne Anzeige dass der Dienst aktiviert ist, aber wenn ich mich zu meinem Problemchen recht entsinne hieß das nicht automatisch, dass der Dienst auch tatsächlich läuft.


    Ich würde da, wie im ersten Post von mir beschrieben, erst einmal kontrollieren, ob der SMB-Dienst auf der TS, welcher für die Windows-Freigaben im Netzwerk verantwortlich ist, tatsächlich überhaupt läuft. Dazu brauchen wir dann den Telnet oder SSH Dienst auf der TS. Der lässt sich unter QNAP-Oberfläche->Systemsyterung->Netzwerkdienst->Telnet/SSH aktivieren. Ob Telnet oder SSH ist für's lokale Netzwerk zwar irrelevant, für die folgend beschriebenen Schritte ebenfalls. Wenn sich SSH aber anbietet würde ich das bevorzugen. Also Häkchen bei "SSH-Verbindung zulassen" auf Port 22.


    Als nächstes benötigen wir ein Terminal-Progrämmchen. Da bei Win7 aber der Telnet-Client von Haus aus schon nicht installiert ist, würde ich "putty" bervorzugen. Das gibt's hier: http://www.chiark.greenend.org…atham/putty/download.html
    Wir benötigen für unsere Zwecke nur die "putty.exe"


    Putty starten, die IP-Adresse der TS eingeben -> "open" und schon sind wir mit der TS verbunden. Die abgefragten Login-Daten entsprechen den Anmeldedaten auf der Web-Oberfläche. Voreingestellter Verbindungstyp bei putty ist ssh.


    Dann einfach mal


    Code
    ps | grep smb


    eintippen. Damit lässt sich kontrollieren, ob der smb-Dienst tatsächlich läuft. Wenn die Rückmeldung sich auf


    Code
    22662 admin       564 R   grep smb


    beschränkt, läuft der Dienst nicht. Die Zahlenangaben (=Prozess-IDs) variieren hier mit Sicherheit, das ist aber nicht relevant.


    Ein laufender Dienst würde so aussehen:


    Code
    2856 admin      3608 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
     2881 admin      1228 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
    24379 admin       576 S   grep smb


    Bitte einmal versuchen, bis hierhin zu kommen und Info, ob der Dienst läuft oder nicht. Falls nicht, wovon ich mal ausgehe, helfe ich gerne weiter die smb.conf mit den Standard-Freigaben wieder herzustellen.


    Gruß,
    McPan

  • Hallo McPan,



    danke für die schnelle und ausführliche Beschreibung bis dahin. Das lässt sich super nachverfolgen, auch ohne Kenntnisse von SSH :D



    Noch ein paar Kleinigkeiten, die ich vielleicht hätte erwähnen sollen. Die Adminoberfläche lässt sich problemlos aufrufen und dort läuft auch alles einwandfrei. Es wurde einmal eine Festplatte disconnected, danach habe ich das System neu gestartet und das Raid 5 wurde wieder hergestellt. Seit dem fehlen alle Freigabeordner (in der Adminoberfläche). Sie müssen aber noch da sein, denn ich kann Neue hinzufügen, diese werden aber auch nicht angezeigt bzw. wollte ich die Standardordner wiederherstellen mit der Fehlermeldung, dass diese schon da wären.


    Terminal ist kein Problem, da ich mit Mac arbeite und da ist das Terminal standard.


    Ich bin deiner Beschreibung gefolgt und wie Du schon vermutet hast läuft der smb-Dienst nicht (Windowsnetzwerk ist aktiviert im Adminbereich, da OS X das genauso verwenden kann wie Windows)


    Code
    14931 admin       564 R   grep smb


    So weit, so (un)gut.

  • Hallo DeGe,


    das mit "Festplatte diconnected" sieht meinem Problem ja verblüffend ähnlich. Da der smb-Dienst nicht läuft ist die Konfiguration hier möglicherweise auch hinüber. Du könnest eventuell noch prüfen, ob im smb-logfile Fehlermeldungen, ähnlich wie oben beschrieben, auftauchen. Vermutlich ja.


    Code
    cat /var/log/log.smbd


    Dann haben wir zwei Möglichkeiten, wieder an deine Daten zu kommen. Als MAC-User könntest du dir das Programm "cyberduck" besorgen, unter Windows wäre "WinSCP" geeignet. Beides sind Filemanager, welche sich Remote via SSH verbinden können.


    Möglichkeit 1, wenn nur schnell noch Daten benötigt oder gesichert werden sollen:
    Mit Cyberduck/WinSCP zur TS verbinden. Die Daten sollten im Verzeichnis "/share/MD0_DATA/" liegen (zumindest bei meiner TS 210 liegen sie da). Da könnest du dir schon mal auf deinen Arbeitsrechner sichern was du noch schnell benötigst.


    Möglichkeit 2, smb.conf wieder herstellen:
    Da ich nicht weiß wieviel von deiner smb.conf noch überig ist und die QNAP-default-conf ja keine Standard-Freigaben beinhaltet, könnest du dir den unten angezeigten Inhalt als Textdatei mit Namen "smb.conf" abspeichern. Diese Konfiguration entspricht der Standard-Konfiguration ohne benutzerspezifische Verzeichnisse. Die Zugriffsrechte beschränken sich auf den User "admin" und müssen ggf. im Anschluss, wenn der Dienst wieder ordentlich läuft, für deine Benutzer über die QNAP-Oberfläche wieder angepasst werden.


    Code
    [global]passdb backend = smbpasswdworkgroup = WORKGROUP	security=user	server string=NAS Server	encrypt passwords = Yesusername level = 0	map to guest = Bad Usernull passwords = yes	max log size = 10name resolve order = host bcastsocket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=65536 SO_RCVBUF=65536os level = 20preferred master = no	dns proxy = No	smb passwd file=/etc/config/smbpasswd		username map = /etc/config/smbusers	guest account = guest	directory mask = 0777	create mask = 0777oplocks = yes	locking = yes	disable spoolss = yes	load printers = noforce directory security mode = 0000veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/.@__qini/.Qsync/.upload_cache/.qsync/.qsync_sn/	delete veto files = yesmap archive = nomap system = nomap hidden = nomap read only = nodeadtime = 10use sendfile = yesdisplay charset = UTF8unix extensions = nostore dos attributes = yesclient ntlmv2 auth = yesdos filetime resolution = noinherit acls = yeswide links = yesforce unknown acl user = yestemplate homedir = /share/homes/DOMAIN=%D/%Udomain logons = nomin receivefile size = 4096case sensitive = autodomain master = autolocal master = noenhance acl v1 = yesremove everyone = nokernel oplocks = nomangled names = noprintcap cache time = 0dos charset = ISO8859-1[Multimedia]comment = System default sharepath = /share/MD0_DATA/Multimediabrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = "guest"read list = @"everyone"write list = "admin"valid users = "root",@"everyone","admin"inherit permissions = yes[Download]comment = System default sharepath = /share/MD0_DATA/Downloadbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = "guest"read list = write list = "admin"valid users = "root","admin"inherit permissions = yes[Recordings]comment = System default sharepath = /share/MD0_DATA/Recordingsbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = "guest"read list = write list = "admin"valid users = "root","admin"inherit permissions = yes[Web]comment = System default sharepath = /share/MD0_DATA/Webbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = "guest"read list = write list = "admin"valid users = "root","admin"inherit permissions = yes[Usb]comment = System default sharepath = /share/MD0_DATA/Usbbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = "guest"read list = write list = "admin"valid users = "root","admin"inherit permissions = yes[Public]comment = System default sharepath = /share/MD0_DATA/Publicbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = "guest"read list = @"everyone"write list = "admin"valid users = "root",@"everyone","admin"inherit permissions = yes[homes]comment = System default sharepath = /share/MD0_DATA/homesbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = read list = write list = "admin"valid users = "root","admin"inherit permissions = yes[home]comment = Homepath = %Hbrowsable = yesoplocks = yesftp write only = noinherit permissions = yesinvalid users = guestwritable = yesread list = "%u"write list = "%u"valid users = "%u"root preexec = /sbin/create_home -u '%q'[Qsync]comment = Qsyncpath = /share/Qsyncbrowsable = yesoplocks = yesftp write only = noinherit permissions = yeswritable = yeswrite list = read list = "%u"valid users = "%u"vfs objects =


    Diese smb.conf kannst du dann via Cyberduck/WinSCP auf die TS in das Verzeichnis "/etc/config/" schieben. Dieses Verzeichnis ist ein Symlink auf das eigentliche Verzeichnis "/mnt/HDA_ROOT/.config". Falls Cyberduck mit Symlinks nicht umgehen kann (haben keinen MAC) in das letztere Verzeichnis schieben. Die alte smb.conf von dort vielleicht vorher einmal sichern.


    Damit sollte der Dienst schon wieder startbar sein.


    Bitte hier vorher kontrollieren, ob die Verzeichnisnamen stimmen. Meine ursprünglichen Freigaben hatten teilweise noch ein "Q" im Namen, beispielsweise "QMultimedia". Eventuell muss das in der obigen Konfiguration angepasst werden.


    Feintuning:


    Falls du noch weitere Freigabeverzeichnisse außer den Standards angelegt hast, kannst du dir die folgende Sektion für ein angenommenes Verzeichnis "MEINFREIGABENAME"


    Code
    [MEINFREIGABENAME]comment = System default sharepath = /share/MD0_DATA/MEINFREIGABENAMEbrowsable = yesoplocks = yesftp write only = norecycle bin = yesrecycle bin administrators only = nopublic = yesinvalid users = "guest"read list = @"everyone"write list = "admin"valid users = "root",@"everyone","admin"inherit permissions = yes


    ans Ende der smb.conf anhängen. Das Ganze für jedes zusätzlich erstellte Verzeichnis wiederholen.


    Für die Benutzerverzeichnisse wird ähnlich verfahren. Hier für den Benutzer "USERNAME" den Bereich


    Code
    [USERNAME]comment = path = /share/MD0_DATA/USERNAMEbrowsable = yesoplocks = yesftp write only = norecycle bin = norecycle bin administrators only = nopublic = yesinvalid users = read list = write list = "USERNAME"valid users = "root","USERNAME"inherit permissions = yes


    für jeden angelegten Benutzer anhängen. Bei den Namen für Freigaben, Verzeichnis- und Benutzernamen bitte auf identische Groß- und Kleinschreibung achten!


    Dienst starten:


    Danach kannst du versuchen, über das SSH-Terminal mit

    Code
    /etc/init.d/smb.sh start


    den smb-Dienst wieder zu starten. Die Reaktion sollte dann ungefähr so aussehen:

    Code
    locks path was set to /share/MD0_DATA/.locksStarting winbindd services:Starting SMB services:.


    was aber noch nicht unbedingt bedeutet, dass der Dienst wieder läuft. Dies ist nur der Startversuch. Anschließend also wieder

    Code
    ps | grep smb


    Läuft der Dienst? Wenn ja, sollten die Freigaben wieder zur Verfügung stehen und es müssen die Berechtigungen für deine Benutzer mit der QNAP-Oberfläche wieder angepasst werden.
    Wenn nein: bitte den Inhalt des smb-logfiles posten.


    Gruß,
    McPan

  • Hammer! Es funktioniert. Ich komme wieder an alle Daten ran.



    Ich habe mich für Möglichkeit 1 entschieden und mit erstmal wieder alle wichtigen Daten beschafft bzw. lädt das noch eine Weile. Die Möglichkeit 2 ist sehr ausführlich, doch befürchte ich, dass mich das etwas überfordert ;).


    Wenn ich mich nicht irre kann ich, nachdem ich wieder alle Daten habe und diese auch geprüft habe, den QNAP komplett zurücksetzen, formatieren und alles wieder richtig einstellen. Diesmal werde ich aber auch dessen Konfiguration speichern, damit mir das nicht wieder passiert. Korrekt?



    Auf jeden Fall erstmal ein dickes DANKE :thumb:

  • Hallo DeGe,


    so geht's auch. Daten sichern und zurück auf Werkseinstellung, anschließend wieder einrichten. Konfiguration sichern im Anschluß schadet nicht, dann kann man sich den obigen Klamauk ersparen.


    Bei der Gelegenheit wäre dann vielleicht auch ein Vollständiger SMART-Check (QNAP-Oberfläche, Systemsteuerung->Systemeinstellungen->Speichermanager->Festplatten-SMART->Test) für alle Platten angebracht, bevor du deine Daten wieder auf die TS kopierst. Wenn da eine Platte im sterben liegen sollte wäre jetzt der richtige Zeitpunkt zum Austausch.


    Gruß,
    McPan