J.Nerdy

This popped up today: so far only occurrence. ec 20 02:24:54 nerdyRAID kernel: CIFS VFS: sends on sock 000000002eed1320 stuck for 15 seconds Dec 20 02:24:54 nerdyRAID kernel: CIFS VFS: Error -11 sending data on socket to server Dec 20 02:25:18 nerdyRAID kernel: Status code returned 0xc0000128 STATUS_FILE_CLOSED Dec 20 02:25:18 nerdyRAID kernel: CIFS VFS: Send error in read = -9

There seem to be some miscellaneous issues regarding catalina’s deprecation of smb1 for smb3 in documentation online. That said, it started happening prior upgrading to 10.15 Purely making an educated guess... I think it has to do with samba 4.11 and macOS. If I have some time I may downgrade to 6.7.2 since the issue was absent until upgrading to 6.8 I appreciate you digging in on it... but it is log spam (and low priority) as near as I can tell since no functionally is compromised. Happy Holiday

Cheers permissions are correct, right?

total 0 drwxrwxrwx 2 nobody users 0 Dec 16 21:13 BACKups/ drwxrwxrwx 2 nobody users 0 Nov 30 14:57 ISO_IMG/ drwxrwxrwx 2 nobody users 0 Sep 21 09:33 MEDIA/

Disabled netbios and made sure WSD was enabled. Errors persist.

Using enhanced log, I am not seeing VM start-up or other messaging - is this normal?

macOS 10.15.x defaults to smb3 (which was introduced with its rollout - deprecating smb1 support). I really do appreciate your diligence. What is so perplexing about the error is despite protesting security mismatch, the network device is still mounted R/W with complete access. Wacky. Thanks!

1) very cool plugin - I wish I knew about this earlier 2) indeed it mask the SMB sig errors... 3) see the pic, I will do the same for smb2_readyv_callback (they are clearly related to the samba issues and only persist when accessing the remote mount) How do I troubleshoot the issues with Samba? While I appreciate the help (and am grateful should it continue), this appears to be an "edge-case" and honestly, is not an issue with UD ... but rather how CIFS | SMB network mounts are borked on my system.

Here ya go. nerdyraid-diagnostics-20191215-1135.zip

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.

thank you... know about battery (replacement on way) will look air UD at report back. it occurs on stopping the array as well, not just a cold shutdown or restart. EDIT: @dlandon really odd, so I: removed checksum plugin checked UD for devices with no serial (all devices identified by serial or SMB address) changed VM timeout to 300 changed disk timeout to 420 added ssh,bash to tips|tweaks (I do leave a shell open sometime...thats a great little tidbit) stopped the array... and got an unclean shutdown detected decided to shutdown to create diagnostic log in flash (last one is from 10/16) ... and server shutdown cleanly?? It seems that stopping the array from the GUI is triggering something... since shutdown was clean, not diagnostic was created...is there another troubleshooting path to go down?