Samba Server is sometimes not working

  • Hi,


    i had no Problems with rthe Samba Server with LibreELEC 9. After a new installation of LE 10 the samba server is sometimes down. I see the directories in the home dir but to my HDDs. After a restart all is working fine. Is there a problem with the server? I have the problem with all clients (android smartphone and tablet, windows on my desktop computer and linux on my notebook).

  • What hardware is the SMB server running on?


    Never mind... Guess I was still semi-conscious at the time of reading.

  • The notebook is connected via wifi, the desktop via Ethernet. If the Mount dont work with one device all others also dont work. Its not a Problem with the Ethernet or wifi.


    Can i check whether samba is running correct using systemctl?

  • There is nothing in the log that helps solving the problem:


    Code
    -- Journal begins at Tue 2021-11-30 18:10:16 CET, ends at Tue 2021-11-30 18:38:14 CET. --
    Nov 30 18:10:17 LibreELEC systemd[1]: Starting Samba SMB Daemon...
    Nov 30 18:10:17 LibreELEC systemd[1]: Started Samba SMB Daemon.
    Nov 30 18:10:17 LibreELEC smbd[969]: [2021/11/30 18:10:17.620652,  0] ../../lib/util/become_daemon.c:135(daemon_ready)
    Nov 30 18:10:17 LibreELEC smbd[969]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections



  • I would run

    journalctl -u smbd

    directly after the smb server appears to be down (when it was running before)

    or run it with "-f" ("f" for ~follow up~) all the time

    journalctl -u smbd -f

    or

    journalctl -f


    to see all what's up with your box

    maybe with increased log level:

    [Chapter 4] 4.8 Logging Configuration Options


    ===

    btw.:

    the smb server box is connected via ethernet, too ?


    ===

    maybe something in your smb.conf is ~slightly~ wrong (full wrong => smb wouldn't start)

    run [1]

    testparm -v


    I'm unsure here: I guess it cry's when error are found, anyway I fetched the return status via "echo $?" where I guess "0" means no errors


    one of this has caused trouble for some users (I guess the first one)

    server max protocol ?

    server min protocol ?


    [1]

    I've attached the output of testparm -v

    be aware:

    - it's from nightly

    - it's the untouched default, cause smb is here NOT in use


    if you've a linux box available you could e.g. use "meld" to compare yours and mine

    Meld


    There is nothing in the log that helps solving the problem:

    journal log files are thrown away when you reboot the box ...

    and you just checked for smb only, so maybe it's not smb (my bet: it's network ...[if you don't find any weird config settings with testparm] or it's something with the kernel)

    last part could be checked with nightly (newer kernel: 5.15.y)

  • You may like to enable persistent (journal) logging via the LE Settings Addon to have a history.

  • can i start the journalctl by default every time i start the HTPC?

    "journalctl" or exactly "systemd journal (in short: journald)" *is* started by default.


    but on LE the log's go per default and without adjustment (see comment #9) to RAM only (thrown away at reboot/shutdown, because they could become very large and could fill up the disk)


    "journalctl" is the command to query the systemd journal

    DigiBit R1, NUC8i3BEH

    Edited 2 times, last by JoeAverage ().

  • I had the problem again a few days ago and here is the log.


    Code
    journalctl -u smbd -f
    -- Journal begins at Tue 2021-12-14 14:17:02 CET. --
    Dec 14 14:17:02 LibreELEC systemd[1]: Starting Samba SMB Daemon...
    Dec 14 14:17:02 LibreELEC systemd[1]: Started Samba SMB Daemon.
    Dec 14 14:17:02 LibreELEC smbd[968]: [2021/12/14 14:17:02.625961,  0] ../../lib/util/become_daemon.c:135(daemon_ready)
    Dec 14 14:17:02 LibreELEC smbd[968]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections



    Quote

    the smb server box is connected via ethernet, too ?


    yes.


    Quote

    one of this has caused trouble for some users (I guess the first one)

    server max protocol ?

    server min protocol ?


    i tried all compinations from sm1 to smb3. its the same every time.

  • to be honest: the last log files your provided (to me) have less worth to nail the bug, cause incomplete

    from the 1. : "daemon 'smbd' finished starting up and ready to serve connections" => all seems okay [1]

    from the 2.: something regarding Mesa => nothing to do with interrupted connections

    from the 2.: ... r8169 0000:03:00.0: invalid short VPD tag 00 at offset 1


    for the last one regarding r8169 (your LAN driver) I could find bug reports, but all aged, some years back and without solution.

    search string was "invalid short VPD tag"


    problems with LAN driver would support my theory it's network and not samba...

    therefore complete log files are needed !


    regarding incomplete logs

    =======================

    to me it seems you didn't configured journald keeping the logs files (against @mglae's advise)

    didn't you ?

    maybe I'm wrong, but => "- Journal begins at Tue 2021-12-14 14:17:02 CET. --"


    when the logging begins after the error occured (you said: "I had the problem again a few days ago... versus "Journal begins at Tue 2021-12-14") then you can't find something about the error in that log's !

    is clear ?


    in general:

    - either you configure the box to keep the log's over reboots/shutdowns

    Addon => LibreElec Configuration => System => Logging => "Use Persistent Logs"

    OR

    - you keep the box (the samba server) running until the error occurs

    for the first case you should notice the date/time on a piece of paper when you mention the error on/with your second box for easier searching afterwards.

    are you able to ssh into the samba server then (right now after you mentioned the error) ?


    ===

    anyway, I compared the output of your testparm with a default (unchanged) from my nightly.

    I further need to mention:

    my samba isn't active.

    means it could be that some default entries changes during activation and I guess that is case for "username map"


    the diffs. are (first: my, second: yours):


    1.

    map to guest = Bad User versus

    map to guest = Never


    2.

    min domain uid = 1000 versus

    no entry in yours


    3.

    server min protocol = SMB2_02 versus

    server min protocol = SMB2


    4.

    username map = versus

    username map = /run/samba/samba.map


    hint: "username map =" is in my testparm empty


    other diffs.: I have in all shares [Update], [Video], ... additional this: guest ok = Yes


    hint: samba set some defaults, seeable via testparm, even if they're not explicit configured in smb.conf.

    "guest ok" could be one of them [2]


    I have no idea why all above diffs. exists, but for a test case your could put my entry (exclusive: "username map" !) in your smb.conf esp.

    "server min protocol".

    backup your current smb.conf before !!!


    your need to restart samba afterwards, usually with "systemctl restart smb" or a reboot of the box will do too

    (easily forgetable): your need restart samba everytime after you changed the smb.conf


    [1]

    in ~20 years I've never seen that a samba server shares sometimes and sometimes not. [3]

    either it didn't start or it starts without to be able to make connections to it

    in short: to me it seems your problem is not samba


    [2]

    I guess one could configure a complete empty [global]- section in smb.conf and all defaults are sharp.


    [3]

    but I've seen this with file sharing between two M$ boxes (~ win XP <=> Win 9x)

    a by M$ known bug with attribut: Won't fix !

    DigiBit R1, NUC8i3BEH

    Edited 8 times, last by JoeAverage ().

  • could you check if wsdd2 is running:


    systemctl status wsdd2.service


    it should read:

    Active: active (running) since ...


    else

    systemctl enable wsdd2.service

    and

    systemctl restart wsdd2.service

    DigiBit R1, NUC8i3BEH