sittingmongoose

Just tried that. No longer gettings errors on the Nas, but my server still wont mount it. Saying this in the log. un 20 16:03:15 9900K unassigned.devices: Removing configuration '//NAS1/user-pool.nas1megashare'. Jun 20 16:03:34 9900K flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update Jun 20 16:04:37 9900K avahi-dnsconfd[22338]: read(): EOF Jun 20 16:04:44 9900K unassigned.devices: Mounting Remote Share '//NAS1/user-pool.nas1megashare'... Jun 20 16:04:44 9900K unassigned.devices: Mount SMB share '//NAS1/user-pool.nas1megashare' using SMB default protocol. Jun 20 16:04:44 9900K unassigned.devices: Mount SMB command: /sbin/mount -t 'cifs' -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,credentials='/tmp/unassigned.devices/credentials_user-pool.nas1megashare' '//NAS1/user-pool.nas1megashare' '/mnt/remotes/NAS1_user-pool.nas1megashare' Jun 20 16:04:44 9900K kernel: CIFS: Attempting to mount \\NAS1\user-pool.nas1megashare Jun 20 16:04:44 9900K kernel: CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE Jun 20 16:04:44 9900K kernel: CIFS: VFS: \\NAS1 Send error in SessSetup = -13 Jun 20 16:04:44 9900K kernel: CIFS: VFS: cifs_mount failed w/return code = -13 Jun 20 16:05:08 9900K kernel: CIFS: VFS: \\NAS1\Media2 Close interrupted close Jun 20 16:05:08 9900K kernel: CIFS: VFS: \\NAS1\Media2 Close cancelled mid failed rc:-9

Here you go. 9900K is the server trying to access the Nas1. The other way around works though. 9900k-diagnostics-20220620-1528.zip nas1-diagnostics-20220620-1529.zip

So that allowed me to see it again, but I cant mount it still. I am getting this error. Jun 20 14:24:04 9900K kernel: CIFS: VFS: \\NAS1 Send error in SessSetup = -13 Jun 20 14:24:04 9900K kernel: CIFS: VFS: cifs_mount failed w/return code = -13

Having an issue with one of my rootshares after updating unraid. I have two servers, Server and Nas. Previously I was on RC4. Both saw each others rootshares via smb. Rootshares were configured by unassigned plugin. After updating to 6.10.3 though, my Nas can see my servers rootshare, but my server cant see my Nas rootshare. I tried deleting the rootshare and making it, and I tried rebooting. It wouldnt mount it before, but now that its deleted it, its not showing in my list of available shares. It does show other shares that I can connect to. I can also still connect to the other shares I need to, its just the rootshare I cant see in the list anymore.

I just wiped unraid and did a fresh install like 4 hours ago...I wish this was like 6 hours earlier lol

So i removed the script that @dlandonsuggested thinking maybe that was why i was randomly disconnecting. It lasted 48 hours but it happened again Now some of my dockers cant see my media2 share but others can? Krusader and bazarr cant, but sonarr,radarr, and plex can? I just unmounted and remounted the media2 share manually and it appears to be working. I am posting the diag 9900k-diagnostics-20220417-1308.zip

Yep, double checked it.

I’m not actually seeing anything saying it’s unmounted. I will just check my dockers randomly after a reboot(30 minutes-6 hours later) and they will complain because my /nas1/media2 is missing. Then I’ll reboot the docker and it will still complain. (Even though krusader sees it fine) so I’ll reboot and it will be fine for some time.

So I’m not actually having a problem with the rootshare. I only use rootshare randomly with krusader. My dockers strictly use media2. The share I’m having an issue with is the Media2 share.

I was using remotes, I'll try disks. Thank you

I know that's why it's so weird. Edit: I think its auto reconnecting, and krusader is ok with that but radarr, sonarr, plex are not. Nope, I did that. And all my remote shares are "read/write slave"

Hey, so I thought NFS was just unstable, and my Nas kept unmounting. I have been running SMB for the last year and it was fine. So I switched back to SMB and its still unmounting. It seems to unmount and then remount, but my dockers get pissed off and then i need to restart all my dockers for it to see the smb share again. So something changed in the last week to cause this. I am attaching my diag. Edit: I actually need to reboot the entire server to get my dockers to see the share again...even though krusder can see them? 9900k-diagnostics-20220415-0958.zip

It seems to be functioning correctly. Would you be able to provide instructions to filter that out of my log? I also want to state again, that I really appreciate how responsive you are and how much you help everyone. So thank you again for helping me with my endless problems.

This is exactly what I needed thank you. So is there any hope to fix the error im getting every minute? Apr 14 13:23:58 Nas1 kernel: CIFS: VFS: \\9900K\user-pool.9900kmegashare Close unmatched open for MID:9803351 I only get it on the smb connected rootshares between the two unraid servers. I use rootshare because I manage them frequently through krusader. Maybe a solution would be to use nfs? Is there a way to mount the rootshares through NFS?

Could you include an option to try to reconnect I mounted shares if they are set to auto mount? Maybe try again after 5,10,15 minutes?

I do have krusader referencing it…but I do in my other server too. I’ll try changing that and seeing if that stops FCP. Do the auto mounts keep trying? So for example if I reboot my server and nas at the same time, the nas boots faster. Once the server comes back, they should both eventually reconnect right? I am running ubiquiti equipment. Jumbo was on for both my dream machine and switch. I turned both off. Edit: Took /mnt/user/ out of my krusader template. It didnt fix FCP. All of my dockers are using /mnt/user/appdata/ is that a problem? Thats how my other server is and its not complaining. I only have two dockers on my Nas, syncthing and krusader. Syncthing doesnt have user called out except for the appdata folder. I also restarted my network equipment and did a reboot of both servers. The nas which comes back first did not automount to the server. But the server when it came back second did automount to the Nas. Is this expected behavior? Posting diags for both again. nas1-diagnostics-20220413-1721.zip 9900k-diagnostics-20220413-1725.zip

I do not have anything set to mount them. I just have the set to auto mount through unassigned devices. After I rebooted though, they didn’t auto mount. So I clicked mount. As for the FCP issue. I am terrified to touch it. It says I have an extra User share, but I never made one. I looked and it seems like that is where all my shares are? And my other server looks the same but that one isn’t flagged by FCP? I’m afraid to mess with it though for fear of blowing my Nas up. Granted I don’t have much on that nas except media, but still. I am not good with file systems in linux at all. I would be more than happy to offer a small bounty to someone if they want to hold my hand through fixing it.

Ok, so I had Jumbo frames on. I turned that off. I also deleted the Downloads share(I wasnt using it anyway). I rebooted both servers. I am still seeing the errors. I attached my diagnostics again. BTW, I want to thank you for sifting through all my issues. You have helped me figure out a lot of other issues I have been having, so I appreciate that. Apr 13 11:23:16 9900K kernel: CIFS: VFS: \\NAS1\user-pool.nas1megashare Close unmatched open for MID:773600 Apr 13 11:23:48 9900K kernel: CIFS: VFS: \\NAS1\user-pool.nas1megashare Close unmatched open for MID:776748 Edit: I also attached my second server which has the same errors. This one might be easier to look at because it has a lot less stuff on it. 9900k-diagnostics-20220413-1122.zip nas1-diagnostics-20220413-1139.zip

So still getting all these weird errors in my log. I attached my diag again. Apr 13 00:26:51 9900K kernel: CIFS: VFS: \\NAS1\user-pool.nas1megashare Close unmatched open for MID:335382 Apr 13 00:27:54 9900K kernel: CIFS: VFS: \\NAS1\user-pool.nas1megashare Close unmatched open for MID:343600 Apr 13 00:28:25 9900K kernel: CIFS: VFS: \\NAS1\user-pool.nas1megashare Close unmatched open for MID:346564 Apr 13 00:28:57 9900K kernel: CIFS: VFS: \\NAS1\user-pool.nas1megashare Close unmatched open for MID:349543 Apr 13 00:30:32 9900K kernel: CIFS: VFS: \\NAS1\user-pool.nas1megashare Close unmatched open for MID:358330 Apr 13 00:31:03 9900K kernel: CIFS: VFS: \\NAS1\user-pool.nas1megashare Close unma9900k-diagnostics-20220413-0031.ziptched open for MID:361262

Are you not able to access appdata through your rootshare? I dont see it in my rootshares. Also I attached my diagnostics to make sure everything looks better than before. Edit: It seems the one can see the others appdata, but the other one can not. Is there a way to control this? 9900k-diagnostics-20220412-2105.zip

I can try all that and report back. Thank you

So I was having the issues roughly around 3:30est. I unmounted the nfs share and switched back to smb. I attached the diagnostics.

Should i try to redo the mount from scratch using nfs with debug on? Maybe that will also tell you why i keep getting that connection close error? I only want to do it if its actually valuable to you because it messing my whole system up and i get no warning that things are messed up unless i go and manually check krusader or some specific media thats on my nas through plex.

@dlandon hey, so whatever you changed in that last patch to make nfs connect at v4 is making my connection unstable. It was pretty reliable for the last 2 days using it, but since that patch, it’s now flaking out after like 15-45 minutes. It still shows mounted though but it’s not. Unmounting and remounting fixes it until it poops out again. Oddly it’s just doing that on 1 of my two servers. edit: nfs is connected via disks instead of remotes(if that’s a problem)

I am using remotes, should I use disks? And it’s happening when I’m not transferring data. Like they aren’t really being used at all. The nfs connection is but the rootshare isn’t. Also, I dont think any dockers even have dockers pointed to the rootshares, the only exception is krusader. Even my windows VMs are just mounting the rootshares through the network and not through the unassigned devices mount.