dlandon

You're talking about mappings in general, not necessarily remote shares?

Is there really that much mapping to remote share local mounts? Somebody give me some examples please. I'm just not getting it.

I'm pondering a solution that no one will even notice. I'm thinking of mounting remote shares to /mnt/remotes and adding symlinks to the /mnt/disks/ mount point for remote shares so all existing apps will still work, and recommend that as people add new apps, and modify older apps, they begin to use the /mnt/remotes mount point.

Please update UD. Rolling back the remote share mount point change. It would create too many support issues for very little gain.

Anyone running UD on 6.9 please take note:

For those running 6.9, you will need to do one of three things when updating to the new version of UD: Unmount all remote shares, update UD, then mount remote shares. Update UD, then stop the server and re-start. Update UD and reboot. If you want to roll back to 6.8 (do this while running 6.9): Unmount remote share. Click on the mount point text to change the mount point. Click 'Change' to update the mount point. If you roll back to 6.8, any changed Docker container or VM mappings can still use the /mnt/remotes local mount point. Once UD is updated, change all your Docker container or VM remote share local mount points to /mnt/remotes/...share.

Update UD again. I'm limiting the change to version 6.9 and above. UD will never unmount anything when updating. The change only applies to new mounts. The check for UD not mounting the share was only because it was unfortunately checking the /mnt/disks mount point and not the /mnt/remotes mount point.

If you look at the log when you try to unmount the remote share, there will probably be a log message about it can't be unmounted because UD did not mount it. This is because of the change in the mount point. I'll work on an update to UD this morning to fix that.

You should be good to go.

Set up a VPN.

No, that's the only way UD can determine if the server is online.

The mount button is greyed out because the remote server is not responding to a ping - UD thinks the server is offline. Be sure the server is configured to respond to a ping.

Which share didn't mount? I don't see the problem.

I've just released a new version of UD. The main new features: You can now limit the scope of UD to disks only, shares only, or both. If you don't need remote shares, you can turn that feature off. Remote shares are now mounted at /mnt/remotes and not /mnt/disks to separate the mount points for disk devices and remote shares. If you use a remote share local mount point in a Docker container or VM, you should redo them to the new mapping. To verify where the mount point is mapped, mount the share and then click on the mount point text to browse the remote share. At the top of the page, you should see /mnt/remotes/... If the share is still mapping to /mnt/disks, you can unmount the share, then click on the mount point text to change it. Just click 'Change' and the mount point will be corrected.

UD can only find those disks discovered by Linux and not assigned to the array. Nothing in UD has changed for many months regarding finding unassigned disks. I think it would be best for @JorgeB to jump in here. He is the expert on disks and controllers.

This looks like the only disk not assigned to the array: devs ( [d..0] => Array ( [id] => Samsung_SSD_860_PRO_2TB_S5G7NS0N600130K [tag] => 0 [device] => sdl [sectors] => 4000797360 [sector_size] => 512 ) ) This is from the vars array that shows what Unraid says is unassigned. You have 15 disks assigned to the array, plus cache, and parity. One disk is unassigned. That's 18 disks total. You have 18 disks showing in the smart.txt of the diagnostics. If you have more disks, there is an issue with your port multiplier?

That's useless. I want to see the source server name/ip address so I can understand why the server on-line check is not working. I guess I'll just have to guess at a solution.

Can you at least provide a screen shot of the remote shares of concern?

The diagnostics are anonymized. If you feel they aren't enough, post a request to Limetech about your concern. It can be difficult to help without diagnostics. At least show me a screen shot.

Just happen to be sitting at the computer. Tools->Diagnostics In the future always post diagnostics to get you an answer quicker.

Post diagnostics and a screen shot of the remote shares.

Why are you mapping to a remote share? That's not a good idea. If the remote server goes offline, Zoneminder will not have access to the path and will have all kinds of issues. Map it to a local disk and set up a user script to copy it to the Synology on a schedule.

Show how you mapped the config and data paths.

I've updated UD and removed the force SMB v1 setting. There is no reason for it any longer.

This: Nov 23 11:40:15 NAS unassigned.devices: Mount SMB share '//10.0.1.10/Data' using SMB1 protocol. Nov 23 11:40:15 NAS unassigned.devices: Mount SMB command: /sbin/mount -t cifs -o rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=1.0,credentials='/tmp/unassigned.devices/credentials_Data' '//10.0.1.10/Data' '/mnt/disks/time-capsule' It's missing 'sec=ntlm'.