dlandon

Can you updatde the 6.11.5 server to 6.12?

I'm seeing this in the log: Apr 29 07:15:56 NAS rpc.mountd[6334]: v4.0 client detached: 0x602ff7716405b917 from "192.168.8.30:702" Apr 29 07:18:05 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 9 TIMES] ### Apr 29 07:18:19 NAS ool www[4016]: Successful logout user root from 192.168.8.120 Apr 29 07:18:19 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 14 TIMES] ### Apr 29 07:18:43 NAS webGUI: Successful login user root from 192.168.8.120 Apr 29 07:18:44 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 6 TIMES] ### I'm not sure what this means, but the workgroup on your servers is not the same. Unraid is ToK, NAS is TOK. Windows doesn't care about the case because it is always upper case in Windows. Linux may deal with it differently though because of the case difference.

Unless you are using AD, leave it blank.

This is the command that is used on Unraid to mount your remote share: /sbin/mount -t cifs -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=3.1.1,credentials='/tmp/unassigned.devices/credentials_Unraid' '//DS918/Unraid' '/mnt/remotes/DS918_Unraid' The credentials file contents are: username= password= domain= Try the command on Unraid and modify the options, etc and see if one of them is un-compatible with Synology. I'm wondering if you didn't set a domain when you set up the share.

By your screen shot, you're on 6.11.5. This post is about 6.12.0-rc5. Move your post to the UD forum, post diagnostics again and we'll carry on there.

I just realized I've not gotten your diagnostics. You just posted a log snippet. Please post diagnostics so I can see more of your setup.

You don't use a password on the remote share? Just a username?

Can you post the mount command from the Linux VM so I can compare?

Which version of SMB was successful in mounting to the Synology. UD attempts to mount the remote share with the following sequence of SMB versions: None to see if the remote server offers a version it supports. then 3.1.1 then 3.0 then 2.0 finally 1.0 The next version is tried if the previous version fails. It may be that the Synology needs a specific version not included here, and I need to add another version to try. Maybe NFS would be a better solution to mount the Synology remote share in your case.

I don't think so. I think you are confusing Windows browsing of shares with Unraid doing a CIFS mount. They are different. I have no issues mounting remote shares and have not heard of anyone else having issues like what you are having. I'll keep looking, but I don't see anything. The think the CIFS mount error is coming from the Synology and not from Unraid. The research I did was of no help with this error code so I don't have any other suggestions.

This is confusing. How does Windows mount the Synology? Navigating the share how?

You are mounting the same remote share using CIFS and NFS and not sharing either one with SMB or NFS locally: May 2 19:34:04 Unraid unassigned.devices: Mounting Remote Share '//192.168.8.25/Backups'... May 2 19:34:04 Unraid unassigned.devices: Mount SMB share '//192.168.8.25/Backups' using SMB default protocol. May 2 19:34:04 Unraid 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_Backups' '//192.168.8.25/Backups' '/mnt/remotes/NAS_Backups' May 2 19:34:04 Unraid kernel: Key type dns_resolver registered May 2 19:34:04 Unraid kernel: Key type cifs.idmap registered May 2 19:34:04 Unraid kernel: CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount. May 2 19:34:04 Unraid kernel: CIFS: Attempting to mount \\192.168.8.25\Backups May 2 19:34:04 Unraid unassigned.devices: Successfully mounted '//192.168.8.25/Backups' on '/mnt/remotes/NAS_Backups'. May 2 19:34:04 Unraid unassigned.devices: Device '//192.168.8.25/Backups' is not set to be shared. May 2 19:34:04 Unraid unassigned.devices: Mounting Remote Share 'NAS.KOENIG.SE:/mnt/user/Backups'... May 2 19:34:04 Unraid unassigned.devices: Mount NFS command: /sbin/mount -t 'nfs4' -o rw,noacl 'NAS.KOENIG.SE:/mnt/user/Backups' '/mnt/remotes/NFS_NAS_Backups' May 2 19:34:04 Unraid kernel: NFS: Registering the id_resolver key type May 2 19:34:04 Unraid kernel: Key type id_resolver registered May 2 19:34:04 Unraid kernel: Key type id_legacy registered May 2 19:34:04 Unraid nfsrahead[37996]: setting /mnt/remotes/NFS_NAS_Backups readahead to 128 May 2 19:34:04 Unraid unassigned.devices: Successfully mounted 'NAS.KOENIG.SE:/mnt/user/Backups' on '/mnt/remotes/NFS_NAS_Backups'. May 2 19:34:04 Unraid unassigned.devices: Device 'NAS.KOENIG.SE:/mnt/user/Backups' is not set to be shared. Both will provide a local mount point that differ in name - '/mnt/remotes/NAS_backups' and '/mnt/remotes/NFS_NAS_Backups'. Why are you doing this? One mount point with either protocol will accomplish the same thing. What are you trying to accomplish? Both mount points will have the same information from the remote share. Use one protocol or the other on a remote share and not both, While UD permits this, I can't say this is a good idea and is probably why you are seeing the CIFS errors. I'm not sure how each protocol would respond to local /mnt/remotes/... file changes that end up getting reflected in the remote share. i.e. writes to both mount points. I'm honestly thinking that UD should probably prevent this scenario.

Show a screen shot of how the remote share is setup. This is the Shares->Share Settings page.

This is your issue: May 1 17:42:54 Loki kernel: CIFS: VFS: cifs_mount failed w/return code = -512 SMB uses port 445, but CIFS also needs port 139. Since you have PCs that can connect, I suspect there is an issue with port 139. Check the firewall on the Synology and verify both ports (445 and 139) are open in the firewall. If they are, toggle them off and back on again. Then see if Unraid can connect. I did a little research and found this was a solution on another server that was not a Synology NAS, but the same principle might apply. What changed you may ask? Well it seems that Microsoft and samba are in a continuous cat and mouse chase here. Each update in Windows and samba can bring on new issues as Microsoft and samba up their security. Any update on a server or client can bring new challenges.

This is coming from a UD remote share mount. What is the remote server at 192.168.8.25?

What probably happened was the 'Share' default was changed to not share for security reasons. If you've never changed the 'Share' switch, it would still be at the default.

May 2 10:47:21 Weechflix unassigned.devices: Successfully mounted '//JESTER/Music' on '/mnt/remotes/JESTER_Music'. May 2 10:47:21 Weechflix unassigned.devices: Device '//JESTER/Music' is not set to be shared. Set the device share switch:

Post diagnostics.

Check on the Synology and see if there are settings that controls CIFS mounts. I assume the Windows and Mac PCs were only browsing the shares and not mounting them with CIFS.

UD waits for up to two minutes for the network to become available before trying to mount remote shares. This is to be sure the remote shares can be mounted.

It looks like you are using NFSv3 that is not supported on your remote server: May 1 21:32:22 U-RJO21 unassigned.devices: Mount NFS command: /sbin/mount -t 'nfs' -o rw,noacl 'U-NAS23:/mnt/user/data' '/mnt/remotes/U-NAS23_data' May 1 21:32:22 U-RJO21 rc.docker: ApacheGuacamole: started succesfully! May 1 21:32:23 U-RJO21 kernel: br-3a5431a8c481: port 2(vethf665a10) entered blocking state May 1 21:32:23 U-RJO21 kernel: br-3a5431a8c481: port 2(vethf665a10) entered disabled state May 1 21:32:23 U-RJO21 kernel: device vethf665a10 entered promiscuous mode May 1 21:32:23 U-RJO21 kernel: mdcmd (38): nocheck pause May 1 21:32:23 U-RJO21 kernel: md: recovery thread: exit status: -4 May 1 21:32:25 U-RJO21 unassigned.devices: NFS mount failed: 'mount.nfs: requested NFS version or transport protocol is not supported '. Go to Settings->Unassigned Devices and set NFSv4 protocol and try to mount it.

Your server is not responding to a mount command, or it is taking too long. Is port 445 open to your remote server? It looks like you are accessing the remote server through the Internet. Check with your Internet provider to be sure it's not being blocked. Hopefully you are using a VPN to connect the two servers. Did you let UD search for the remote shares on that server or set it up manually? You should set up the remote share using the IP address for the server, then let UD find the available shares. If you don't get a list of the shares, port 445 is probably not open.

Update UD.

The issue is with hot plugged disks. I'll have a fix today.

New release of UD. Highlights: Added a 'Read Only' switch to remote shares so they can be mounted read only. Fixed special character handling of iso file names that was causing the endless Unraid wave. Some cleanup on remote shares to align text in the table for better readability. Text box for NFS rules so multiple rules can be set for each device. Default force user nobody to 'No' on SMB shares. Some protections to prevent blank serial number or device entries in the config files. Fixed the situation where the same devX name in Historical devices would only show one device. Two devices with the same default devX name is valid and is changed as necessary when the device is reinstalled or attached. Unraid fixes the devX designation so each active device has a unique designation. As stated earlier, if you see the endless Unraid Wave, delete the /flash/config/plugins/unassigned.devices/iso_mount.cfg file, click on the double arrows at the upper right of the UD page, and re-enter your iso shares.