Probleme bei Einbindung von Samba-Freigaben (Zeitstempel)

[btuxx]

Hallo zusammen,

seit langem binde ich meine NAS-Freigaben bei Manjaro KDE nach diesem Muster in fstab ein:

//192.xxx.xxx.xxx/Backups /mnt/Backup cifs user,x-systemd.automount,noauto,iocharset=utf8,username=name,password=geheim,domain=workgroup,uid=1000,gid=1000,file_mode=0644,dir_mode=0755 0 0

bisher gab es damit auch keine Probleme.

Seit (vermutlich) dem letzten Update erhalten auf allen Rechnern alle Dateien, die ich auf das NAS speichere das jeweils aktuelle Datum und Uhrzeit des Kopierzeitpunktes.
Ich habe schon etliche Varianten bei file_mode und dir_mode ausprobiert, leider ohne Erfolg. Auch der Wechsel auf testing hat keine Änderung gebracht.
Interessanterweise haben einige auf das NAS kopierte Verzeichnisse ihren ursprünglichen Zeitstempel behalten, jedoch eine Dateien.
Das ist neu, nicht gewollt und nervt.
Wenn ich die Netzwerkfreigabe über Dolphin anspreche, bleibt der ursprüngliche Zeitstempel erhalten.
Ein Kubuntu-Rechner zeigt diesen Fehler nicht.

Mache ich etwas falsch oder hat sich beim Update ein Fehler eingeschlichen?

[SpiritOfTux]

//192.xxx.xxx.xxx/Backups /mnt/Backup cifs user,x-systemd.automount,noauto,iocharset=utf8,username=name,password=geheim,domain=workgroup,uid=1000,gid=1000,file_mode=0644,dir_mode=0755 0 0

Überprüfe dein NAS, welche Samba-Version hier läuft,
trage dann die Versionnr. in den MountPoint ein ( V=)
schlage dies aber vorher nochmals nach.

[btuxx]

Ich habe jetzt in der Zeile noch "vers=3.0" eingetragen. Dies hat das Problem aber leider nicht gelöst.

So ganz verstehe ich das auch noch nicht. Wie kommt es, dass das Problem erst vor kurzem bei mir auftrat.

Leider kann ich nicht genau nachvollziehen seit wann. Auf jeden Fall hat es im September mit gleichen Einstellungen noch einwandfrei funktioniert.

[SpiritOfTux]

Ich habe jetzt in der Zeile noch "vers=3.0" eingetragen. Dies hat das Problem aber leider nicht gelöst.

OK

"vers=3.0"
So ganz verstehe ich das auch noch nicht. Wie kommt es, dass das Problem erst vor kurzem bei mir auftrat.

Dies ist schon lange Standard bei allen Systemen die mit Samba arbeiten

Aus deinem Profile kann man nicht ersehen welchen Desktop , Kernel etc verwendet wird

Code: [Auswählen]

inxi -Fnxxxazo


[btuxx]

Desktop KDE
Kernel 5.9.8-1
das ganze auf 3 verschiedenen Systemen Intel und AMD

Was mit nicht einleuchtet, ist, dass wenn ich mit Dolphin temporär auf das NAS zugreife der Zeitstempel original bleibt, aber wenn ich über fstab auf das gleiche Verzeichnis schreibe, der Zeitstempel verändert wird.

Ich habe auch mal Vers=2.0 eingetragen, das hat auch keinen Effekt gehabt.

Das Verhalten ist neu und bei allen Manjaro-Rechnern (stable und testing) auf.

Bei einem Kubuntu-Rechner tritt dies nicht auf.

[SpiritOfTux]

Ich habe auch mal Vers=2.0 eingetragen, das hat auch keinen Effekt gehabt.

Irgendwie habe ich den Eindruck sich zu bemühen die Samba-Version auf dem NAS
zu ermitteln nicht ankommt; siehe hier

« am: Heute um 10:25:07 »

Zu:

Desktop KDE
Kernel 5.9.8-1

Tipp

Setze die LTS Kernel ein, nicht die DEV Kernel wie 5.9
oder den linux58 5.8.x dieser hat den Status [EOL], der
Support wird eingestellt.

Nur mit den LTS-Kernel kommen auch neue Treiber und Firmware Code,
nicht unbedingt für die DEV-Kernel.

Die Entwicklung der Treiber und des Firmware Code erfolgt immer auf
Basis der LTS-Kernel

Zu:

Was mit nicht einleuchtet, ist, dass wenn ich mit Dolphin temporär auf das NAS zugreife der Zeitstempel original bleibt, aber wenn ich über fstab auf das gleiche Verzeichnis schreibe, der Zeitstempel verändert wird.

Das Verhalten ist neu und bei allen Manjaro-Rechnern (stable und testing) auf.

siehe hierzu https://de.manjaro.org/index.php?topic=8449.msg53307#msg53307

Zu:

Bei einem Kubuntu-Rechner tritt dies nicht auf.

Packages_Based_On: Manjaro Linux (*.tar.gz)    Debian (*.deb)  Redhat (*.rpm)

Based_On_Manjaro Linux: Rolling Release System (Top Aktuell)
Based_On_Debian:        Teil - Aktualiesierung; nicht mit Manjaro Linux vergleichbar
Based_On_Redhat:        Teil - Aktualiesierung; nicht mit Manjaro Linux vergleichbar

[btuxx]

Irgendwie habe ich den Eindruck sich zu bemühen die Samba-Version auf dem NAS
zu ermitteln nicht ankommt; siehe hier

Ich habe das schon richtig verstanden. Vers. 3.0 ist die richtige. Vor lauter Verzweiflung habe ich mir jedoch erlaubt auch Dinge auszuprbieren, die auch mir nicht logisch erscheinen in der abwegigen Hoffnung es könnte doch passen...

Tipp

Setze die LTS Kernel ein, nicht die DEV Kernel wie 5.9
oder den linux58 5.8.x dieser hat den Status [EOL], der
Support wird eingestellt.

Danke für den Tipp, das leuchtet mir ein, 5.4.77-1 hat aber leider keinen Erfolg gebracht.

Zu:
siehe hierzu https://de.manjaro.org/index.php?topic=8449.msg53307#msg53307

Leider erkenne ich daraus nicht den Unterschied zu der Einbindung über fstab (vielleicht fehlen mir da auch ein paar Zusammenhänge).

Zu:
Packages_Based_On: Manjaro Linux (*.tar.gz)    Debian (*.deb)  Redhat (*.rpm)

Based_On_Manjaro Linux: Rolling Release System (Top Aktuell)
Based_On_Debian:        Teil - Aktualiesierung; nicht mit Manjaro Linux vergleichbar
Based_On_Redhat:        Teil - Aktualiesierung; nicht mit Manjaro Linux vergleichbar

Die grundsätzlichen Unterschiede sind mir bekannt und bewusst, ich frage mich nur, was in der letzten Zeit bei Manjaro durch Updates geändert wurde und zu meinem Problem führt. Bin ich evtl. der einzige?

Beim Runterfahren des einen Rechners habe ich für einen sehr kurzen Monent folgende Fehlermeldung sehen können:

"Failed to start Samba SMB Daemon." Damit konnte ich bei der Suche nichts finden, was ist wirklich verstanden habe. Eine Datei samba.conf existiert bei mir nicht.

Mittlerweile werde ich immer ratloser...

[SpiritOfTux]

"Failed to start Samba SMB Daemon." Damit konnte ich bei der Suche nichts finden, was ist wirklich verstanden habe. Eine Datei samba.conf existiert bei mir nicht.

Na dies ist doch mal ein Info,
Überprüfe den Status von Smba

Code: [Auswählen]

sudo systemctl status smb.service
erscheinen hier Meldung unterhalb von

● smb.service - Samba SMB Daemon

die Meldungen anzeigt und auf eine PID zeigt starte das

Code: [Auswählen]

journalctl -b
und suche diese PID, hier befinden sich weitere nützliche Info's

Info's zu https://wiki.manjaro.org/index.php/Using_Samba_in_your_File_Manager
              https://wiki.archlinux.org/index.php/samba

[btuxx]

Danke erstmal für Deine ausdauernde Hilfe.
Hier das Ergebnis von dem Rechner mit der Fehlermeldung beim Runterfahren:

● smb.service - Samba SMB Daemon
     Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Sun 2020-11-15 15:47:17 CET; 26min ago
       Docs: man:smbd(
             man:samba(7)
             man:smb.conf(5)
    Process: 931 ExecStart=/usr/bin/smbd --foreground --no-process-group $SMBDOPTIONS (code=exited, status=1/FAILURE)
   Main PID: 931 (code=exited, status=1/FAILURE)

Nov 15 15:47:16 bv-PC2 systemd[1]: Starting Samba SMB Daemon...
Nov 15 15:47:17 bv-PC2 systemd[1]: smb.service: Main process exited, code=exited, status=1/FAILURE
Nov 15 15:47:17 bv-PC2 systemd[1]: smb.service: Failed with result 'exit-code'.
Nov 15 15:47:17 bv-PC2 systemd[1]: Failed to start Samba SMB Daemon.

Ergebnis von "journalctl -b"

-- Logs begin at Sat 2020-08-15 18:04:08 CEST, end at Sun 2020-11-15 16:15:18 CET. --
Nov 15 15:47:09 bv-PC2 kernel: microcode: microcode updated early to revision 0x40, date = 2020-02-27
Nov 15 15:47:09 bv-PC2 kernel: Linux version 5.4.77-1-MANJARO (builder@dbee9b79dde5) (gcc version 10.2.0 (GCC)) #1 SMP PREEMPT Wed Nov 11 12:25:12 UTC 2020
Nov 15 15:47:09 bv-PC2 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.4-x86_64 root=UUID=xxx rw quiet cryptdevice=UUID=yyy>
Nov 15 15:47:09 bv-PC2 kernel: KERNEL supported cpus:
Nov 15 15:47:09 bv-PC2 kernel:   Intel GenuineIntel
Nov 15 15:47:09 bv-PC2 kernel:   AMD AuthenticAMD
Nov 15 15:47:09 bv-PC2 kernel:   Hygon HygonGenuine
Nov 15 15:47:09 bv-PC2 kernel:   Centaur CentaurHauls
Nov 15 15:47:09 bv-PC2 kernel:   zhaoxin   Shanghai 
Nov 15 15:47:09 bv-PC2 kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Nov 15 15:47:09 bv-PC2 kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Nov 15 15:47:09 bv-PC2 kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Nov 15 15:47:09 bv-PC2 kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Nov 15 15:47:09 bv-PC2 kernel: x86/fpu: xstate_offset[3]:  576, xstate_sizes[3]:   64
Nov 15 15:47:09 bv-PC2 kernel: x86/fpu: xstate_offset[4]:  640, xstate_sizes[4]:   64
Nov 15 15:47:09 bv-PC2 kernel: x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format.
Nov 15 15:47:09 bv-PC2 kernel: BIOS-provided physical RAM map:
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000003efff] usable
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000000003f000-0x000000000003ffff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x0000000000040000-0x000000000009dfff] usable
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000000009e000-0x00000000000fffff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x0000000000100000-0x000000000fffffff] usable
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x0000000010000000-0x0000000012150fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x0000000012151000-0x000000005b869fff] usable
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005b86a000-0x000000005d962fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005d963000-0x000000005d99bfff] usable
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005d99c000-0x000000005d9d2fff] ACPI NVS
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005d9d3000-0x000000005dd76fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005dd77000-0x000000005ddd0fff] type 20
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005ddd1000-0x000000005e14dfff] usable
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005e14e000-0x000000005e14efff] ACPI NVS
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005e14f000-0x000000005e178fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005e179000-0x000000005e755fff] usable
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005e756000-0x000000005e757fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005e758000-0x000000005effffff] usable
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x000000005f000000-0x000000007fffffff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x00000000d0000000-0x00000000d0ffffff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x00000000fe042000-0x00000000fe044fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x00000000fe900000-0x00000000fe902fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
Nov 15 15:47:09 bv-PC2 kernel: BIOS-e820: [mem 0x0000000100000000-0x000000047fffffff] usable
Nov 15 15:47:09 bv-PC2 kernel: NX (Execute Disable) protection: active

Auf dem AMD-Rechner kommt folgende Meldung:

● smb.service - Samba SMB Daemon
     Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: man:smbd(
             man:samba(7)
             man:smb.conf(5)

sieht auch nicht wirklich gut aus.
Auf beiden Rechnern das selbe Problem.

Leider bin ich dann bei der Interpretation überfordert...

[SpiritOfTux]

Kleine Info, vorsichtig mit dem Posten großer Log-File's, sieht der Admin nicht gern 

Zu:

Process: 931 ExecStart=/usr/bin/smbd --foreground --no-process-group $SMBDOPTIONS (code=exited, status=1/FAILURE)
   Main PID: 931 (code=exited, status=1/FAILURE)

Jetzt versuch mal aus dem journal die Info's zu selectieren
wenn ich dies noch richtig erinnere

Code: [Auswählen]

journalctl -b | grep _PID=931
zeigt uns die relevaten Info's

smb.service - Samba SMB Daemon

[btuxx]

Kleine Info, vorsichtig mit dem Posten großer Log-File's, sieht der Admin nicht gern 

Das dachte ich mir auch schon, deshalb hab ichs auch nur von einem PC hochgeladen, ich dachte aber, es sei wichtig, denn

Code: [Auswählen]

journalctl -b | grep _PID=931


hat leider nix ausgegeben 

[SpiritOfTux]

Das dachte ich mir auch schon, deshalb hab ichs auch nur von einem PC hochgeladen, ich dachte aber, es sei wichtig, denn

hat leider nix ausgegeben 

Nicht gut 

Code: [Auswählen]

journalctl -F _PID _SYSTEMD_UNIT=smb.service


[btuxx]

Da gibts folgende Ausgabe:

Extraneous arguments starting with '_SYSTEMD_UNIT=smb.service'


(auch in rot)

[SpiritOfTux]

Code: [Auswählen]

sudo journalctl _PID=931


[btuxx]

...ich hab da jetzt nur den "Rest" reinkopiert, ansonsten fängt das im August an und ist eben ziiieeeemlich lang:

Okt 07 15:24:22 bv-PC2 ksplashqml[931]: QCoreApplication::arguments: Please instantiate the QApplication object first
Okt 07 15:24:23 bv-PC2 ksplashqml[931]: file:///usr/share/plasma/look-and-feel/org.kde.breath2.desktop/contents/splash/Splash.qml:144: ReferenceError: webFont is >
-- Reboot --
Okt 19 06:45:21 bv-PC2 sddm-helper[931]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
-- Reboot --
Okt 29 06:56:26 bv-PC2 sddm-helper[931]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
-- Reboot --
Nov 02 06:38:48 bv-PC2 sddm-helper[931]: Adding cookie to "/home/bv/.Xauthority"
-- Reboot --
Nov 04 20:58:25 bv-PC2 gvfsd[931]: A connection to the bus can't be made
lines 307-353/353 (END)