Samba fails after awhile

[someonestolemyusername]

I'm encountering serious instability using Samba on TrueNAS Scale. Seemingly randomly smbd stops responding to clients.

Output of uname -a:

Code:

Linux truenas.home 5.10.81+truenas #1 SMP Mon Dec 20 21:03:38 UTC 2021 x86_64 GNU/Linux

smbd version: 4.15.2-TrueNAS

Here's the content of the logs.smbd file since last service restart:

Code:

  smbd version 4.15.2-TrueNAS started.
  Copyright Andrew Tridgell and the Samba Team 1992-2021
[2022/02/10 20:55:13.149134,  1] ../../lib/param/loadparm.c:1766(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "syslog only" option is deprecated
[2022/02/10 20:55:13.151060,  1] ../../source3/profile/profile.c:54(set_profile_level)
  INFO: Profiling turned OFF from pid 3755167
[2022/02/10 20:57:02.447512,  1] ../../lib/param/loadparm.c:1766(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "syslog only" option is deprecated
[2022/02/10 20:57:02.488107,  0] ../../source3/modules/smb_libzfs.c:840(zhandle_get_dataset)
  zhandle_get_dataset: Failed to stat dataset mounpoint [legacy] for dataset [MSA60-DAS01/.system]: No such file or directory

If there are any other logs that would be of help, please let me know.

 

[anodos]

I'm encountering serious instability using Samba on TrueNAS Scale. Seemingly randomly smbd stops responding to clients.

Output of uname -a:

Code:

Linux truenas.home 5.10.81+truenas #1 SMP Mon Dec 20 21:03:38 UTC 2021 x86_64 GNU/Linux

smbd version: 4.15.2-TrueNAS

Here's the content of the logs.smbd file since last service restart:

Code:

  smbd version 4.15.2-TrueNAS started.
  Copyright Andrew Tridgell and the Samba Team 1992-2021
[2022/02/10 20:55:13.149134,  1] ../../lib/param/loadparm.c:1766(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "syslog only" option is deprecated
[2022/02/10 20:55:13.151060,  1] ../../source3/profile/profile.c:54(set_profile_level)
  INFO: Profiling turned OFF from pid 3755167
[2022/02/10 20:57:02.447512,  1] ../../lib/param/loadparm.c:1766(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "syslog only" option is deprecated
[2022/02/10 20:57:02.488107,  0] ../../source3/modules/smb_libzfs.c:840(zhandle_get_dataset)
  zhandle_get_dataset: Failed to stat dataset mounpoint [legacy] for dataset [MSA60-DAS01/.system]: No such file or directory

If there are any other logs that would be of help, please let me know.

Hmm... that libzfs error is usually benign, but it does indicate that you are sharing the root of your zpool rather than a dataset (which is generally not a good idea).

 

[anodos]

What version of SCALE is this?

 

[someonestolemyusername]

What version of SCALE is this?

TrueNAS-SCALE-22.02-RC.2

 

[someonestolemyusername]

Hmm... that libzfs error is usually benign, but it does indicate that you are sharing the root of your zpool rather than a dataset (which is generally not a good idea).

I'm sharing out a folder from the root. My zpools weren't originally created in TrueNAS, they were imported from another system.

 

[Samuel Tai]

TrueNAS expects NOT to share out from the root. You'll have to restructure your pool to move the share to a daughter dataset.

 

[anodos]

When Samba is unresponsive to external clients are you able to connect through loopback through local SSH session?
e.g. "smbclient //127.0.0.1/<share name> -U <your user>"?

Does "service smbd restart" fix the problem?

What OS did the zpool come from?

 

[someonestolemyusername]

When Samba is unresponsive to external clients are you able to connect through loopback through local SSH session?
e.g. "smbclient //127.0.0.1/<share name> -U <your user>"?

Does "service smbd restart" fix the problem?

What OS did the zpool come from?

It's looking like this may be an issue with the second eth interface. I tested against the primary's IP and was able to run smbclient -L
smbclient does work locally
Restarting the service appeared to work in the past but that was likely a fluke (it did not fix hitting the second interface this time).
The pools came from a Proxmox host (Debian).

 

[someonestolemyusername]

Confirmed it was an issue with the second interface, somehow it lost its DHCP address.