This kind of errors for smbd is presented in logs, how to fix it?

NethServer Version: 7.7.1908
Module: smbd, Logs

I have neglected the log review. But since past week a see this:


Added 1: Maybe not related (but yes, looks related), Top shows 100% cpu usage for samba:
image
image
I need to be worried?
What I need to do to fix this?

Note: seems to me that services like smb o nsdc are using/updating an internal database, the cpu usage increases until something is completed, but sometimes this just don’t complete. Then I need to restart some of this two services. But I like to know more before trying to do this again, especially because the log errors from above.


Added 2: I restart the server the cpu usage is normal again and the logs doesn’t show the error
First errors are mine, I write a wrong password.
image

Regards

Could be a shell or permission issue from what I found out:

1 Like

Thank you, I’ll investigate more then.

First I’ll try to disable the shared folders from our NethServer, so I hope to stops seeing this error, at this moment all my users has went to home, that was the moment when I restart our NS. Maybe is the reason of not seeing the reported error in the logs.

We now have a NAS, and is using the AD to authenticate users, and moved the shared folders doc on the NAS.
I wonder if wrong credentials to access the NAS via the AD authentication are registered here in NS logs too?

Thanks again!


Edit1: The error appears again, now this is war! :thinking:
image

I am pretty sure that Windows wants to do something in the background, but I just cannot figure out what (my similar problem in linked thread is still unsolved - btw I do not remember spikes in CPU usage, but possibly just did not notice it when happened).

It appears only if somebody is using the AD joined machine physically.
No errors when only Remote Desktop users are in on the very same machine, or if I access the files from a non-AD joined machine (with file explorer, either locally from WiFi or remotely via VPN).

3 Likes

Maybe the error log began 2 or 5 weeks ago when I started testing the vpn.
I’m connected right now using our vpn (is not the provided with NethServer)

I’ll test using another connecting way but not vpn, to see if the error prevail.

Thank you, regards.


Added: Confirmed, the errors occurs when I’m connected using the VPN. Using the RDP doesn’t trow that kind of warning.
image


Thank you @CptCharlesG and @mrmarkuz

If your VPN is not bridged, meaning it is a separate network, you may need to add the VPN to the trusted networks.

http://docs.nethserver.org/en/v7/base_system.html#trusted-networks

This setting is correct @mrmarkuz?

When we start configuring the vpn this was the route for the VPN that I added.
The other one is to allow some PC to connect to our NS and use the NAS via wireless.

Both are “working”, I can’t remember some issue on the wireless one, but we can print, accessing shared folders on the NAS and browsing.

Yes, the static routes seems correct.

I meant if you use a non-Nethserver VPN, you need to add this VPN to the trusted networks to be able to access shares from VPN on Nethserver, I don’t know about connection to NAS.

(Well, welcome for the VPN idea, but in this case it looks the opposite to my problem.)

The NAS (a synology) is the one where I can’t add more than one route; I research a little and the only way is using the ssh-terminal on the NAS to add more than one route and rebooting.

But currently, we aren’t using the wireless one, this because the CoV-19 and myself outside the premises, and waiting for some usb wireless adapters.

Opps! my mistake, yes they are added in Trusted Networks:

I found a centos bug, user logs in but is in root dir:

https://bugs.centos.org/view.php?id=16719

Maybe we can ignore it?

1 Like

So, this is the reason?
I’m not connected via VPN and the log starts showing the warning, I’m connected using RDP.

I’m worried about this message by the reporter, I hope there is no crash involved here.

I don’t fully understand him but I think it’s not a complete crash but logs an error.
Did you already check the persistent shares of the client? Even if logged in via RDP there may be persistent shares with maybe wrong credentials.
Searching the web leads to many different answers/solutions…

1 Like

Yes, I disable all the shared folders, and I check there is not mapped drive-letters on the old shares (at least my PC and other server aren’t using the old NS shares)
At this moment, there is no more entries (paint me confused)
I’ll try to keep and eye on this for the next days.

Thank you!

1 Like

I think it says something along the lines of a user with a home folder with restricted permissions leads to a failure condition, and then connects to / (root).
User comment sounds similar to a bug reported here in the forums many time ago (and fixed).

1 Like