Beiträge von pschulze59

    Ich glaube, seit dem Update auf Leap 15.0, hat mein physischer Netzwerkadapter immer zwei IP-Adressen (siehe listing), davon ist eine von mir vergeben (192.168.100.91) und die andere existiert sofort immer mit und bekommt seine IP-Adresse vom DHCP-Server (.153).
    Das Doofe daran ist, dass der tatsächlich auch über die DHCP-zugewiesene Adresse kommuniziert und nicht über die manuell festgesetzte (.91). Gwissermaßen ist damit die fest vergebene Adresse nutzlos, weil der Traffic immer über die .153 erwartet wird.
    Lösche ich den Adapter mittels YAST sind beide Adressen weg - setze ich für den Adapter die Adresse manuell fest (.91), sind automatisch beide Adressen da, auch die über DHCP erhaltene (.153).
    Hat jemand eine Idee?


    Ich habe keine virtuellen (zusätzlichen Adressen zugewiesen. Es gibt keinen zweiten physischen oder virtuellen Adapter.
    Ich kann zwar mit

    Code
    ip addr del 192.168.100.153/24 dev eth0

    den virtuellen Adapter löschen - aber dass müsste ich derzeit händisch machen (oder in ein skript einbauen) - aber das kann ja nicht die Lösung sein.

    Prüfe mal, ob wirklich "kein Netz" anliegt, oder "nur" die Namensauflösung nicht funktioniert. Ich pinge dazu einen öffentlichen Server über die IP-Adresse an, z. B. 194.25.2.129 (das ist ein nameserver der Telekom). Bekommst Du Antwort auf die pings, dann funktioniert das Netz, aber die Namensauflösung nicht. Um trotzdem das INternet nutzen zu können, kannst Du dann in der /etc/resolv.conf den nameserver von oben händisch eintragen.

    Also bei meinen Installationen auf verschiedenen Systemen hat BTRFS (fast) immer Probleme gemacht, die plötzlich dann verschwunden waren, als ich wieder auf ext4 umgestellt hatte. Besonders schlimm war es bei RAID1-Systemen. Aber selbst auf einem Desktop-PC mit Samsung-SSD gab es immer wieder Filesystem-Fehler. Es gibt derzeit bei mit ein System mit BTRFS, welches stabil läuft. Da ich Rollbacks nicht brauche - nur noch Hobby und kein professioneller Einsatz mehr - bleibe ich bei dem superstabilen EXT4. Für alle nicht laufenden Programme gebe ich ausschließlich mir selbst schuld - meistens ;-))

    Ich habe auf drei Systemen die Updates gemacht und auf allen lief danach VirtualBox nicht mehr, obwohl die Pakete ebenfalls geupdated wurden.


    Mein Rezept: Deinstalliere über Yast das ganze VirtualBox (die VB-Images und Einstellungen bleiben ja erhalten), dann habe ich über Yast wieder alles installiert. Danach habe ich den Rechner neu gestartet, um sicher zu gehen, dass die kernel-module geladen wurden. Anschließend habe ich die extensions von der virtualbox-website runtergeladen und über die VB-GUI->Einstellungen-> Zusatzpakete installiert. Danach lief alles wie erwartet.

    Und ich habe keine Rechtfertigung erwartet - nur Vorschläge gemacht und Ansätze genannt, die Du verfolgen kannst, aber nicht musst.
    Wenn Du es probiert hast mit dem, was ich nannte, und nicht weiterkommst, dann kannst Du die Ergebnisse hier darstellen. Dein letztes Statement hilft nicht wirklich weiter.
    Im Übrigen glaube ich nicht, dass es "an Samba liegt" ...

    Gut, dann beantworte mal noch die Frage von ThomasS, denn falls Dein Windows in der VM auf der selben physikalischen Maschine läuft, auf der auch das Linux läuft von dem Du zugreifen willst und Deine Virtualisierungssoftware VirtualBox ist, dann brauchst Du doch nur noch in den Einstellungen zur VM einen gemeinsamen Ordner einrichten. Dieser wird dann beim Start der Windows-VM (bei ausgewählter Option) gleich automatisch mit eingehängt - und schon kannst Du aus der VM heraus auf die "Freigaben" (die in dem Fall eigentlich keine sind) auf dem Linux-als VM-Hoster-Server zugreifen.


    Für den Fall, dass Du aber von den Windows-Maschinen (egal, ob als VM oder als echte Clients) auf eine wirkliche CIFS/SMB-Freigabe auf einen Linuxserver zugreifen willst, musst Du alles mit Samba beschriebene tun. Neben einigen notwendigen Einstellungen in der /etc/samba/smb.conf beachte bitte, dass Du je nach Art des in der smb.conf festgelegten Zugriffs-Modus (respektive Benutzerzugriffs-Kontrolle, z. B. bei der Option "security = share" oder "security = user"), auch noch den "Windows"-Benutzer anlegen musst, der ein entsprechendes Pendant im Linux-System haben sollte. Das macht man mit

    Code
    smbpasswd -a username

    Dies könnte der Grund sein, warum nach der Neuinstallation "plötzlich" die Sache nicht mehr geht, weil ja auch die samba-user-Datei neu erzeugt wurde.
    Im security-level "domain" brauchst Du irgendwo einen Domänencontroller, der die Benutzer-Authentisierung übernimmt. Den kann zwar auch Linux darstellen (falls Du keinen "echten" AD-Controller hast, aber das ist ziemlich kompliziert und das scheinst Du nicht zu wollen.


    Vielleicht genügt das als Ausgangshinweis für weitere Recherchen.