J.Nerdy

Copied and umount & mount and still getting log spam (tried rebooting server as well). I also tried digging into folder (disk) ownership. Nothing there worked either. I was on Mojave (which only supported smb1) and upgraded to Catalina which deprecates smb1 for sm3 ... still no joy. I really appreciate your help, I wish I could be of more value. (Just updated plug-in as well).

Agreed. I don't believe this to be a UD problem as other linux users are having similar issue with remote shares - (though it seems to affect windows machines as well in their instances). I think I need to kick this back to as a bug report in 6.8 stable? Though I think it could be a Samba bug...

@dlandon I don't know if this is as much a UD problem as a change in Samba that is causing the issue. Researching around there seems to be open issue with kernel complaining (across distros: red hat, ubunutu etc) about SMB verification error - but still being able to mount and browse the destination - starting in June. Have not found any solid information on solution either.

hmmm it was configure to yes.... odd. I am manually configuring DNS to see if that makes a difference (though it shouldn't) and will report back. Thanks! Edit: I am a knob... I configured the DNS client-side, but did not make the edits to already configured peers. FIXED

Derp! Thank you!

Nothing special, its a pretty simple setup. The thunderbay (6 disk external raid array) is connected and mounted to the Mac through thunderbolt3. I then connect to the MAC (only the thunderbay is shared) through SMB utilizing UD. Prior to 6.8, this worked with no issues. Only after updating did it start logging credential errors. I did (per your suggestion, which is better security hygiene anyway- thank you) create a limited role user with an alphanumeric password. I was hoping the password complexity of the admin account was the issue - but it persists across the new user as well. Oddly, I can access and manipulate the data on the SMB disk just fine - its just filling up my log (an inconvenience, but not a shop stopper). As you noted, it is only when accessing the disk with active read|writes that is begins to spam.

I know that I missing something simple: when using remote tunneled access, I can hit my server and LAN without an issue, but the client can not browse to addresses outside the LAN (internet). I thought maybe it was DNS resolotion, but, entering IP addresses for sites still timeout. (I assume the server is routing all traffic when using tunneled access and sending back to client) Is there a configuration besides setting remote tunneled access that I will need to change?

Remove the share. Added it back. Error persists. The share is accessible (both read and write) to the array and services - it just spams the log multiple times per second when being accessed. Question, how often is the system log purged? Thank you for taking the time to investigate.

@dlandon so it spamming even worse now. I think it is related to a docker. When you refer to credentials, you mean the user credentials for samba mount, correct? EDIT: so I have narrowed it down to this: whenever the docker containers (Plex | CP | qbit) access the data on the remote mounted array (a thunderbay mounted on a Mac mini) it starts to spam the log. I created another user "unRAID" and the passphrase is alphanumeric without any spaces and use that to mount via UD. Is it possible that the samba.conf is still registering the previous credentials as well? They remain valid. Also, it only started after upgrading to 6.8, so is it the new smb2 protocol?

I tried un-mounting and the error persists. I am going to un-mount, turn-off auto mount and reboot server to see if that makes a difference. The credentials DO have special characters. EDIT: rebooting and removing auto mount killed the error. Creating user with alphanumeric and will circle back EDIT 2: Created new user with long alphanumeric chain - mounted, accessible and no more error spamming. Thanks @dlandon EDIT 3: As soon as docker service started, it began spamming again. I wonder why?

@dlandon Syslog is getting crushed with CIFS SMB verification error. (Network mount via UD). This started with upgrade to 6.8 The network mount is credentialed as it is a device attached to a Mac on the network. Diag Attached. nerdyraid-diagnostics-20191213-0848.zip

Will do, thank you

My log is getting crushed with: CIFS VFS: SMB signature verification returned error = - 5 Does this have to do with new SMB protocol? Edit: Diag attached nerdyraid-diagnostics-20191213-0017.zip

Excellent guide and it worked flawlessly, thank you. My knowledge base is thin, so sorry if this question is naive: when active on a client (iPhone) is all traffic routed through wireguard to home LAN, thus encrypted and serving as VPN for safe browsing on unsecured wifi? Or is it just a point to point tunnel that allows for encrypted access to addresses on the servers LAN? Thanks!

So rather than starting and stopping the Win VMs, just set them to hibernate? When hibernating win10 writes the current instance to page file correct, so RAM and pinned cpus will be released back to unRAID? I have always just stopped and started the VMs as needed, so I am unsure how the resources will be affected. @Squid - to clarify, install the qemu-guest-agent-win on the windows instance? Will toggling the VM manager only affect those VMs with agent (eg not my macOS | linux instances)? Thank you both.