systemd mounted nicht RW ( Jessie )

  • Hallo Community,

    ich komme einfach nicht weiter und hoffe nun auf etwas Hilfe oder einen Schubs in die richtige Richtung.

    Hardware: RasberryPi 2 Model B
    Betriebssystem: Rasbian 8, LinuxVersion 4.1.19.V7+

    Mein Problem:
    Beim Starten soll das Netzlaufwerk eines Windows Server eingebunden werden. Dies funktioniert per systemd auch soweit ohne nennenswerte Probleme. Einzig die Berechtigung zum Schreiben in das Verzeichnis wird nicht gewährt.

    Was habe ich bis dato gemacht:
    SD Karte erstell mit Rasbian
    Zwei Unitfiles erstellt ( siehe unterhalb )

    Code
    [Unit] => automount
    Description = Camshareverzeichnis Netzwerk Automount
    [Automount]
    Where = /mnt/camshare
    [Install]
    WantedBy = multi-user.target
    Wants = remote-fs-pre.target


    Code
    [Unit] => mount
    Description = Camshareverzeichnis Netzwerk Mount
    [Mount] 
    What = //server/share/ Testshare
    Where = /mnt/camshare
    Type = cifs 
    Options = username=***,password=***
    [Install]
    WantedBy = multi-user.target
    Wants = remote-fs-pre.target

    Beide Unitfiles “aktiviert”

    Code
    sudo systemctl enable *.mount
    
    
    sudo systemctl enable *.automount

    Neustart
    Zusätzliche Einträge in der /etc/fstab sind nicht vorhanden.

    Fall weitere Informationen nötig sind, bitte melden.

    Gruß
    PI_Guinan

    Einmal editiert, zuletzt von PI_Guinan (14. Juli 2016 um 12:56)


  • Beide Unitfiles “aktiviert”

    Code
    sudo systemctl enable *.mount
    
    
    sudo systemctl enable *.automount

    Neustart
    Zusätzliche Einträge in der /etc/fstab sind nicht vorhanden.

    Wie sind nach dem Neustart, die Ausgaben von:

    Code
    systemctl status *.mount
    systemctl status *.automount


    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo,

    die Ausgaben sehen wie folgt aus ...

    ● mnt-camshare.automount - Camshareverzeichnis Netzwerk Mount
    Loaded: loaded (/etc/systemd/system/mnt-camshare.automount; enabled)
    Active: active (waiting) since Thu 1970-01-01 00:00:03 UTC; 46 years 6 months ago
    Where: /mnt/Camshare

    ● mnt-camshare.mount - Camshareverzeichnis Netzwerk Mount
    Loaded: loaded (/etc/systemd/system/mnt-camshare.mount; enabled)
    Active: failed (Result: exit-code) since Thu 2016-07-14 11:25:14 UTC; 41s ago
    Where: /mnt/camshare
    What: //***/Testshare
    Process: 532 ExecMount=/bin/mount -n //***/Testshare /mnt/camshare -t cifs -o username=***,Password=*** (code=exited, status=32)

    Nach dem ersten Zugriff sieht das dann so aus ...

    ● mnt-camshare.automount - Camshareverzeichnis Netzwerk Mount
    Loaded: loaded (/etc/systemd/system/mnt-camshare.automount; enabled)
    Active: active (running) since Thu 1970-01-01 00:00:03 UTC; 46 years 6 months ago
    Where: /mnt/camshare
    ● mnt-camshare.mount - Camshareverzeichnis Netzwerk Mount
    Loaded: loaded (/etc/systemd/system/mnt-camshare.mount; enabled)
    Active: active (mounted) since Thu 2016-07-14 11:30:09 UTC; 8s ago
    Where: /mnt/camshare
    What: //***/Testshare
    Process: 682 ExecMount=/bin/mount -n //***/Testshare /mnt/camshare -t cifs -o username=***,password=*** (code=exited, status=0/SUCCESS)

    Die Rechte auf die Verzeichnisse lauten wie folgt ...

    Code
    pi@raspberrypi:~ $ ls -l
    total 4
    lrwxrwxrwx 1 pi   pi     13 Jul 14 08:42 camshare -> /mnt/camshare
    drwxr-xr-x 2 root root 4096 Jul 14 08:41 usb
    lrwxrwxrwx 1 pi   pi     12 Jul 14 08:42 userdir -> /mnt/userdir
    pi@raspberrypi:~ $ ls -l /mnt
    total 0
    drwxr-xr-x 2 root root 0 Jul  7 18:49 camshare
    drwxr-xr-x 2 root root 0 Jan  1  1970 userdir

    Einmal editiert, zuletzt von PI_Guinan (14. Juli 2016 um 13:42)


  • Active: active (waiting) since Thu 1970-01-01 00:00:03 UTC; 46 years 6 months ago
      
    Nach dem ersten Zugriff sieh das dann so aus ...

    Evtl. die Unitfiles so gestalten, dass die Ausführung (Start) mehr gegen Ende des Bootprozesses statt findet. Siehe evtl. auch die Ausgabe von:

    Code
    systemd-analyze blame

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Das "Laufwerk" wird ja trotzdem verbunden. Auch wenn es nicht ganz sauber ist. Dennoch würde ich das gerne korrigieren.
    Wie erreiche ich das die Ausführung erst gegen Ende / später stattfindet?

    Allerdings kann ich nicht schreibend auf das Netzlaufwerk / Share zugreifen. Das Hauptproblem bleibt damit bestehen.

    Code
    mkdir: cannot create directory ‘test’: Permission denied

  • Wie erreiche ich das die Ausführung erst gegen Ende / später stattfindet?

    Mit entsprechenden Abhängigkeiten in der [Unit]-Section und evtl. auch mit "Type=idle" in der [Service]-Section mal versuchen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • After network.target remote-fs.target

    Sorry, bin gerade nur am Handy... schau dir die richtige Schreibweise der targets kurz mit "systemctl" an... nur eben überprüfen, dass ich mich hier mit der Syntax nicht falsch erinnert habe.

    Wenn damit der Fehler nicht behoben ist, starte das Netzwerk via systemd-networkd und mounte "after=systemd-networkd-wait-online.service". Da dann alles von systemd geregelt wird, funktioniert das auf jeden Fall. Aber auch hier wieder der kurze Hinweis, vorher eben schnell die Syntax zu bestätigen.

    Einmal editiert, zuletzt von WinterUnit16246 (14. Juli 2016 um 22:51)

  • Habe zwischenzeitlich das ganze etwas angepasst und das Mounten läuft fehlerfrei durch.

    Die Dateien sehen jetzt wie folgt aus und liegen in /etc/systemd/system/

    AUTOMOUNT

    Code
    [Unit]
    Description = Camshareverzeichnis Netzwerk Automount
    Wants=network.target network-online.target
    After= multi-user.target
    [Automount]
    Where = /mnt/camshare
    [Install]
    WantedBy = multi-user.target

    MOUNT

    Code
    [Unit]
    Description = Camshareverzeichnis Netzwerk Mount
    After=network.target network-online.target
    [Mount] 
    What = //***/Testshare
    Where = /mnt/camshare
    Type = cifs 
    Options = username=***,password=***
    [Install]
    WantedBy = multi-user.target

    Die Meldungen von systemctl status ergeben nun folgende Info...

    ● mnt-camshare.automount - Camshareverzeichnis Netzwerk Mount
    Loaded: loaded (/etc/systemd/system/mnt-camshare.automount; enabled)
    Active: active (waiting) since Thu 2016-07-14 16:07:58 UTC; 5min ago
    Where: /mnt/camshare
    Jul 14 16:07:58 raspberrypi systemd[1]: Starting Camshareverzeichnis Netzwer....
    Jul 14 16:07:58 raspberrypi systemd[1]: Set up automount Camshareverzeichnis....
    Hint: Some lines were ellipsized, use -l to show in full.

    ● mnt-camshare.mount - Camshareverzeichnis Netzwerk Mount
    Loaded: loaded (/etc/systemd/system/mnt-camshare.mount; enabled)
    Active: inactive (dead)
    Where: /mnt/camshare
    What: //***/Testshare

    Ich hoffe das das jetzt so richtig ist. Wenn nicht bitte korrigieren.

    Das aus meiner Sicht eigentliche Problem das der "normale" Benutzer Pi nicht in das gemountete Verzeichnis schreiben kann besteht ungeachtet der Änderungen immer noch. Verwende ich z.B. sudo mkdir testverzeichnis funktioniert es ohne Probleme.

    Man möge mich korrigieren falls ich falsch liege. Für mich sieht es so aus als würde mit den Schreibrechten auf das Mount-Verzeichnis etwas nicht stimmen.

    Ich bin so langsam echt am verzweifeln. :helpnew:

  • Das aus meiner Sicht eigentliche Problem das der "normale" Benutzer Pi nicht in das gemountete Verzeichnis schreiben kann besteht ungeachtet der Änderungen immer noch. Verwende ich z.B. sudo mkdir testverzeichnis funktioniert es ohne Probleme.

    Man möge mich korrigieren falls ich falsch liege. Für mich sieht es so aus als würde mit den Schreibrechten auf das Mount-Verzeichnis etwas nicht stimmen.

    Ist auf dem Windows-Server der User "pi" namensgleich und mit gleichem Password als User mit eigenem Account enthalten? Und hat er auf diesem Windows-Server als "lokaler Benutzer" Schreibrechte auf das freigegebene Verzeichnis? Wenn nicht, ist das vermutlich die Ursache. Dann wird der Client-User "pi" zwar das freigegebene Verzeichnis mounten dürfen, aber vermutlich im Guest-Mode eben nur lesend. Der User "pi" mus also auf beiden Maschinen vorhanden sein.

    Es ist aber nicht zwingend notwendig, dass der Client-User "pi" selber mountet. Es muss nur ein User sein, der auf beiden Maschinen bekannt ist, also auch auf dem Windows-Server eingerichtet ist und dort "rw" für das freigegebene Verzeichnis berechtigt ist. Dieser Client-User (oder auch root) kann dann wiederum auf dem Client freigeben, wer das Serververzeichnis schreibend/lesend nutzen darf. Davon kriegt Windows auch nix mit.

    Und noch ein Hinweis: Client-samba kann nicht die Rechte so darstellen, wie sie auf dem Windows-Server tatsächlich gesetzt sind. Deswegen bringt der "ls" auf dem Linux-Samba-Client leider gar nix und enthält keine verwertbare Informationen. Weder der auf dem Windows-Server definierte Besitzer von Dateien und Verzeichnissen, noch das weitaus differenziertere Win-Rechtesystem ist Client-samba bekannt. Das Rechte-System von Windows ist völlig anderes als unter Linux. Samba synchronisiert ja noch nicht einmal die Rechte zwischen Linux-Client und Linux-Server, bzw. können (z.B. mit ls) angezeigte Client-Besitzer/Gruppe eine völlig andere sein, als sie auf dem Samba-Server tatsächlich gespeichert sind. Durch den im mount möglichen uid- und gid-Parameter könnte theoretisch jeder Client-User bei den Mounts als Besitzer (und Gruppe) angezeigt werden, wenn die mounts z.B. dynamisch via pam_mount bei der Anmeldung eines User durchgeführt werden... und davon kriegt der Windows-Server absolut nix mit. Fazit: Die Rechte müssen für den User "pi" auf dem Windows-Server passen, dann wird das wohl auch rw funktionieren.

    Hth

    Einmal editiert, zuletzt von WinterUnit16246 (14. Juli 2016 um 23:02)

  • Moin,
    eventuell hilft ja ein rw in der OPTIONS-Zeile. Ich weiss nicht ob es bei systemd auch default ist. Aber schaden kann es nicht.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Hallo ThomasL,


    Es ist aber nicht zwingend notwendig, dass der Client-User "pi" selber mountet. Es muss nur ein User sein, der auf beiden Maschinen bekannt ist, also auch auf dem Windows-Server eingerichtet ist und dort "rw" für das freigegebene Verzeichnis berechtigt ist. Dieser Client-User (oder auch root) kann dann wiederum auf dem Client freigeben, wer das Serververzeichnis schreibend/lesend nutzen darf. Davon kriegt Windows auch nix mit.

    der User aus dem Code Schnipsel aus der Unit hat die nötigen Rechte.

    Danke, für die Ausführliche Antwort. Leider bewege ich mich noch sehr unsicher in der Linux Welt. Unter Windows ist das eher kein Problem.

    Guinan
    Automatisch zusammengefügt:

    Moin Bernd,

    ich glaube der Hinweis von Dir hat sich mit meinen Überlegungen von heute Nacht überschnitten.


    Moin,
    eventuell hilft ja ein rw in der OPTIONS-Zeile. Ich weiss nicht ob es bei systemd auch default ist. Aber schaden kann es nicht.

    Gruss Bernd

    Ich habe mal folgende Zeile in der Mount Unit geändert / angepasst.

    Code
    Options = username=***,password=***,iocharset=utf8,file_mode=0777,dir_mode=0777

    Der erste "Versuch" sah gut aus. Nur jetzt kommt ein Haken. Seit dem Reboot schlägt der Start von systemd-networkd-wait-online.service fehl und ich bekomme folgende Meldung.

    pi@raspberrypi:~ $ sudo systemctl status systemd-networkd-wait-online.service -l
    ● systemd-networkd-wait-online.service - Wait for Network to be Configured
    Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled)
    Active: inactive (dead)
    Docs: man:systemd-networkd-wait-online.service(8)
    Jul 15 07:48:06 raspberrypi systemd[1]: Dependency failed for Wait for Network to be Configured.
    pi@raspberrypi:~ $ sudo systemctl start mnt-camshare.mount
    pi@raspberrypi:~ $

    Das manuelle starten des Mountvorgangs funktioniert mit dem gewünschten Effekt.

    Ganz ehrlich: Ich habe keine Ahnung welche Abhängigkeiten gemeint sind.

    Da es sich um ein Testsystem handelt werde ich den Pi mit einem neunen Rasbian versehen und das bis hierhin noch einmal testen. Für ein Feedback zu den Abhängigkeiten währe ich dankbar.

    Guinan

    Update

    Leider war die Neinstallation ohne Erfolg was den Fehler mit der systemd-networkd-wait-online.service angeht. Vielleicht bringt der nachfolgende Journalauszug etwas Licht ins Dunkel.

    -- Logs begin at Fri 2016-07-15 08:24:01 CEST, end at Fri 2016-07-15 08:26:49 CEST. --
    Jul 15 08:26:02 raspberrypi sudo[678]: pam_unix(sudo:session): session closed for user root
    Jul 15 08:26:12 raspberrypi dbus[360]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.6" (uid=1000 pid=698 comm="systemctl start systemd-networkd-wait-online.servi") interface="org.freedesktop.systemd1.Manager" member="StartUnit" error name="(unset)" requested_reply="0" destination="org.freedesktop.systemd1" (uid=0 pid=1 comm="/sbin/init ")
    Jul 15 08:26:18 raspberrypi sudo[700]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/systemctl start systemd-networkd-wait-online.service
    Jul 15 08:26:18 raspberrypi sudo[700]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
    Jul 15 08:26:18 raspberrypi systemd[1]: Dependency failed for Wait for Network to be Configured.
    -- Subject: Unit systemd-networkd-wait-online.service has failed
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    --
    -- Unit systemd-networkd-wait-online.service has failed.
    --
    -- The result is dependency.
    Jul 15 08:26:18 raspberrypi sudo[700]: pam_unix(sudo:session): session closed for user root
    Jul 15 08:26:49 raspberrypi sudo[709]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/journalctl -xn
    Jul 15 08:26:49 raspberrypi sudo[709]: pam_unix(sudo:session): session opened for user root by pi(uid=0)

    Einmal editiert, zuletzt von PI_Guinan (15. Juli 2016 um 08:36)

  • Ganz ehrlich: Ich habe keine Ahnung welche Abhängigkeiten gemeint sind.


    Das ist im Grundegenommen relativ simpel..... kompliziert wirds allein dadurch, dass Raspian mehrere Wege zulässt, um nach Rom zu reisen.Wenn Du Dir den Inhalt von systemd-networkd-wait-online.service anschaust, siehst Du die Abhängigkeiten:

    Code
    After=systemd-networkd.service
    Before=network-online.target
    WantedBy=network-online.target

    Im Wesentlichen gehts hierbei um die Unit "systemd-networkd.service", was bedeutet, dass der Service "systemd-networkd-wait-online" nur funktioniert, wenn auch der Service "systemd-networkd" gestartet ist. Bedauerlicherweise ist das bei Raspian (/Debian) nicht der Default-Zustand.... denn, obwohl systemd das Startsystem ist, haben sich die maßgeblichen Entwickler anscheinend dazu entschieden, beim Netz auf die alten Routinen im Zusammenhang mit sysvinit und init.d-Programmen zu setzen. Ich habe diese Entscheidung nie für gut gehalten.... aber seis drum, damit muss man nun leben.
    Um also das Netzwerk auch mit systemd zu starten und die möglichen Features zu nutzen, müssen ein paar Dinge geregelt werden. Dazu gehören:
    - systemd-resolved konfigurieren und starten und enablen
    - systemd-networkd konfigurieren und starten und enablen
    - networking disablen

    Um zu sehen, wie das Netzwerk derzeit bei Dir gestartet wird, machst Du einmal folgendes:

    Code
    systemctl status systemd-networkd


    Solange das allerdings inactive und/oder disabled ist, solltest Du auch den wait-service wieder disablen. Und dran denken, Du darfst das Netz nicht auf zwei Wege versuchen zu starten..... das heisst, nicht gleichzeitig via networking und systemd-networkd.

    Als nächstes schau einfach mal nach, ob das Netzwerk noch mit alter Methode gestartet wird. Der erste Befehl zeigt dir an, ob networking in den Runlevels gestartet wird. Der zweite, wo du das Script networking findest, der dritte zeigt dir den Inhalt der Datei interfaces:

    Code
    find /etc/rc* -iname "*networking" -print
    find /etc -iname "*networking" -print
    cat /etc/network/interfaces

    Möchtest Du das Netz via systemd starten, muss dieser zuletzt festgestellte Kram beseitigt werden. Möchtest Du das Netz weiterhin via runlevels starten, musst Du leider auf den Komfort des Services "systemd-networkd-wait-online" verzichten. Weil es leider keine eindeutige Definition darüber gibt, welchen Zustand "network-online.target" beschreibt und das alte networking das auch nicht unterstützt sind natürlich Probleme bei den remote-fs möglicherweise vorprogrammiert. Das bedeutet, wenn "network-online.target" angezogen wird, definiert das keinen eindeutigen Zustand über das Netzwerk, mehrere Events sind möglich. Vielleicht, wenn die Interfaces geöffnet wurden, oder wenn der NWM gestartet wurde, oder das NIC eine IP hat, oder der Remote-Rechner tatsächlich erreichbar ist. Den tatsächlichen Zeitpunkt einer erfolgreichen Netzverbindung habe ich damals mit einem eigenen Script und einer eigenen Unit "network-wait-online.serve" festgestellt, welches wiederum als Abhängigkeit bei den Mount-Units eingetragen war.

    Mein Rat wäre, wenn Du anstatt der fstab oder eines eigenen rc.local-Mountscriptes die systemd-mounts nutzen möchtest (was ich auf jeden Fall für gut halte), das komplette Netz auf systemd umstellen, mit allen Konsequenzen und konsequent den alten Müll entfernen.

    Einmal editiert, zuletzt von WinterUnit16246 (15. Juli 2016 um 20:23)

  • Hallo ThomasL,

    danke für Deinen ausführliche Antwort / Erklärung.

    Ich habe nun folgendes gemacht:

    1. find /etc/rc* -iname "*networking" –print
    2. find /etc -iname "*networking" –print
    3. cat /etc/network/interfaces

    Du hattest recht der Pi startet wohl via init.d, da ich bei allen Abfragen ein Ergebnis bekommen habe.

    Da ich eigentlich aber unter systemd arbeiten möchte habe ich nachfolgende Änderungen vorgenommen.

    1. systemd-resolved konfigurieren und starten und enablen
    2. systemd-networkd konfigurieren und starten und enablen
    3. networking disablen

    Zu 1. systemd-resolve – vorgenommene Änderungen


    Code
    systemctl enable systemd-resolved.service
    systemctl start systemd-resolved.service
    
    
    nano /etc/systemd/resolved.conf

    # This file is part of systemd.
    #
    # systemd is free software; you can redistribute it and/or modify it
    # under the terms of the GNU Lesser General Public License as published by
    # the Free Software Foundation; either version 2.1 of the License, or
    # (at your option) any later version.
    #
    # See resolved.conf(5) for details
    [Resolve]
    #DNS=

    Die resolved.conf ist „leer“, da ich aktuell keine zusätzlichen DNS-Server verwenden möchte. Basierend auf einer „Besonderheit“ von networkd wird eine dynamische resolve.conf-Datei generiert. Diese wird unter „/run/systemd/resolve/resolv.conf“ bereitgestellt. Diese Datei wird im Anschluss nach „/etc/resolv.conf“ verlinkt.

    Code
    ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
    systemctl restart systemd-resolved.service

    Zu 2. systemd-networkd – vorgenommene Änderungen


    Code
    nano /etc/systemd/network/einbeliebigername.Network

    # Was muss zutreffen, damit die Konfiguration vorgenommen wird?
    [Match]
    # Wildcards sind möglich! "Name=eth*" für die gleichzeitige Konfiguration vieler Interfaces ist denkbar, aber nur selten sinnvoll (Beispiel: DHCP)
    Name=eth0
    # Die Netzwerkkonfiguration
    [Network]
    # Wenn ich kein DHCP verwende...
    DHCP=v4
    # ...lege ich statische Einträge fest.
    #Address=192.168.1.2/24
    #Gateway=192.168.1.254
    #DNS=192.168.1.1

    Code
    systemctl enable systemd-networkd.service
    systemctl start systemd-networkd.service

    Zu 3. networking disablen – vorgenommene Änderungen

    Code
    ifdown eth0
    cp /etc/network/{interfaces,interfaces_bak}


    ifdown eth0 => funktioniert interessanterweise nicht !

    Inhalt der Datei /etc/network/interfaces löschen.

    Code
    update-rc.d networking remove

    Nun neun Abfrage zur Kontrolle …
    1. find /etc/rc* -iname "*networking" –print
    2. find /etc -iname "*networking" –print
    3. cat /etc/network/interfaces

    Hier das Ergebnis …

    pi@raspberrypi:/etc $ find /etc/rc* -iname "*networking" -print
    pi@raspberrypi:/etc $ find /etc -iname "*networking" -print
    /etc/init.d/networking
    /etc/default/networking
    find: `/etc/ssl/private': Permission denied
    pi@raspberrypi:/etc $ cat /etc/network/interfaces

    pi@raspberrypi:/etc $ ifconfig
    eth0 Link encap:Ethernet HWaddr **:**:**:**:**
    inet addr:192.**.**.** Bcast:192.**.**.** Mask:255.**.**.**
    inet6 addr: **::**:**:**:**/64 Scope:Global
    inet6 addr: **::**:**:**:**/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:3453 errors:0 dropped:5 overruns:0 frame:0
    TX packets:2637 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:284707 (278.0 KiB) TX bytes:377102 (368.2 KiB)


    Ich bin mir nicht sicher ob das Ergebnis korrekt ist. Eigentlich dürfte doch laut Konfiguration keine IPV6 Adresse gebunden werden? Ein kurzes Feedback wäre gut bevor ich weitermache.

    Gruß
    Guinan

    Einmal editiert, zuletzt von PI_Guinan (17. Juli 2016 um 11:31)

  • Versuch mal mit:

    Code
    sudo sysctl -w net.ipv6.conf.eth0.disable_ipv6=1


    und wenn OK, dann den entsprechenden Eintrag in die sysctl.conf (oder gleichwertig).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo Community,

    nun schein das Problem gelöst zu sein. An dieser Stelle ein herzliches Dankeschön an alle die hier geantwortet haben.

    Ich noch einmal den Threat zusammenfassen inklusiver der Lösung.

    Problem:
    Beim Starten soll das Netzlaufwerk eines Windows Server mit RW Rechten unter Verwendung von systemd eingebunden werden. Bedauerlicherweise ist das bei Raspian (/Debian) nicht der Default-Zustand.... denn, obwohl systemd das Startsystem ist, haben sich die maßgeblichen Entwickler anscheinend dazu entschieden, beim Netz auf die alten Routinen im Zusammenhang mit sysvinit und init.d-Programmen zu setzen.

    Ausgangslage:
    Hardware: RasberryPi 2 Model B
    Betriebssystem: Rasbian 8, LinuxVersion 4.1.19.V7+
    Sicherheitshalber das System vorher nochmal aktualisieren !

    Lösung: ( umstellen auf systemd )
    1. Prüfen ob de Dienst systemctl status systemd-networkd aktiv ist.
    a) Nein -> Raspbian läuft wahrschienlich als „Mischsystem“
    b) Ja -> sieht schon mal gut aus

    2. Prüfen ob Raspbian als „Mischsystem“ läuft

    Code
    find /etc/rc* -iname "*networking" -print
    find /etc -iname "*networking" -print
    cat /etc/network/interfaces


    Der erste Befehl zeigt an, ob networking in den Runlevels gestartet wird. Der zweite, wo das Script networking vorhanden ist. Der dritte zeigt den Inhalt der Datei Interfaces

    3. Soll das Netz via systemd starten, muss dieser zuletzt festgestellte Kram beseitigt werden.

    4. Bereinigen des alten Kram. ( das erledigt bei mir ein kleines Script ) Evtl. muss das Script an die persönlichen Bedürfnisse angepasst werden. ( Netzwerkkarte eth0 )

    5. Beispiel für eth0.Network

    6. Die Datei resolved.conf existiert normalerweise schon und muss nur angepasst werden.

    7. Nach dem Neustart läuft das System Netzwerktechnisch unter systemd

    Lösung: ( Netzlaufwerk mounten unter systemd )
    1. Erstellt ein .mount-File wie im nachfolgenden Beispiel

    Code
    [Unit]
    Description=Userverzeichnis Netzwerk Mount
    After=network.target network-online.target
    [Mount] 
    What=//***Netzwerpfad auf das Share ***
    Where=/mnt/userdir
    Type=cifs
    Options=username=***,password=***,iocharset=utf8,file_mode=0777,dir_mode=0777
    [Install]
    WantedBy=multi-user.target

    2. Kopieren des .mount-Files in die systemd Hierarchie

    Code
    sudo cp *.mount /etc/systemd/system/

    3. Die Rechte des .mount-Files ändern ( nur zur Sicherheit )

    Code
    sudo chmod -X /etc/systemd/system/*.mount


    Bei mir standen hier Fehler im Boot Protokoll. Datei wurde aber trotzdem abgearbeitet.

    4. Das .mount-File aktivieren

    Code
    sudo systemctl enable *.mount

    5. Mount Punkt anlegen, sonst klappt es nicht. ( /mnt/userdir )

    6. Nach dem Neustart wurden die .mount-Files geladen

    7. Prüfen ob die .mount-Files geladen wurden

    Code
    sudo systemctl status ***.mount

    8. Wenn das .mount-File aktiv ist hat alles geklappt.

    Anmerkungen:
    Wird zusätzlich ein .automount-File verwendet erfolgt das Mounten erst nach/während dem ersten Zugriff auf den Mount-Pfad. Das Ergebnis auf dem Punkt 7 ist dann Inaktiv / dead. Nach dem ersten Zugriff wird es dann aktiv.

    Ich hoffe alles korrekt wieder gegeben zu haben.

    Der Threat ist somit als [SOLVED] anzusehen.

    Gruß
    PI_Guinan

    Einmal editiert, zuletzt von PI_Guinan (18. Juli 2016 um 19:00)

  • Ich hoffe alles korrekt wieder gegeben zu haben.

    Nur noch abschließend ein kleiner nachträglicher Hinweis zum besseren Verständnis... und zwar zu dieser Zeile in Deiner Mount-Unit, wo ein Teil eher für Verwirrung als für Klarheit sorgen kann:

    Code
    Options=username=***,password=***,iocharset=utf8,file_mode=0777,dir_mode=0777

    Die beiden Client-Mount-Parameter (file_mode=0777,dir_mode=0777) haben auf dem Windows-Server keinerlei Einfluss darauf,wie die Rechte auf diesem Server tatsächlich gesetzt sind oder was der Server erlaubt. Selbst wenn Du damit auf dem Client rwx-rwx-rwx bestimmst, hast Du diese Rechte nicht, wenn der Server das nicht ausdrücklich auch erlaubt. Warum? Ganz einfach, nur der Server legt fest, was erlaubt ist und was nicht. Punkt! Das wäre ja eine Katastrophe, wenn sich jeder Client seine eigenen Rechte basteln könnte bzw. sich über vom Server gegebene Rechte hinwegsetzen könnte.

    Was bewirken dies Parameter? Nur die "Lüge", dass Dir überall (Datei-Manager, ls, etc.) rwx-rwx-rwx angzeigt wird, obwohl das tatsächlich vielleicht gar nicht erlaubt ist. Dieser Parameter macht nur im Zusammenhang mit einem echten Samba-Server und dem Eintrag "unix extensions=yes" in dessen smb.conf Sinn. Dann könnte im Rahmen des vom Server erlaubten Rechte-Ranges der Client selber die Rechte setzen.

    Hth

    Einmal editiert, zuletzt von WinterUnit16246 (18. Juli 2016 um 21:24)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!