1 minute ago, b0m541 said:

Sure, knock yourself out:

 

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.

9 minutes ago, dlandon said:

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.

Sorry, you asked for a screenshot So the names are as follows:

Source: //servername.subnet.tld/foldername

Mountpoint: SERVERNAME.SUBNET.TLD_foldername

 

servername small caps, including alphanumeric characters and "-" dash

all other components: small caps alphabetic characters

 

How does the online test work? ping servername.subnet.tld shows that ICMP ECHO works.

Also mounting the share manually on unraid does work without problems.

 

Edited November 25, 20205 yr by b0m541

It definitely must be the DNS name handling. When I use the IP of the server, it does work.

 

The DNS resolution does work on unraid using ping. forward and reverse zone are properly set up.

One note:

the servername I had used is a CNAME / alias. The reverse lookup of that IP is a different DNS name.

 

I tried with the A record name instead of the CNAME. The online check does also fail.

 

PS: I am quite sure that for diagnosing that, the diagnostics would have been of no big help.

 

 

Edited November 25, 20205 yr by b0m541

On 11/22/2020 at 2:57 AM, dlandon said:

Click on the + icon to show the partitions, then click on the check mark to check the file system.  See if that doesn't fix the file system.

Ya still did not work, but the new release you did seems to have done the trick. I can now mount unmount remove readd remount without issue.

The issue with being unable to mount remote shares if DNS domain names are used for the server has been fixed in 2020.11.25a.

@dlandon Thank you for the quick solution! Great responsiveness!

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.

Having an issue with a new SMB share that is in a remote location. All Windows machines can connect to the share without issue, unassigned devices cannot

My old SMB shares seem to be working just fine.

I have included my diagnostics files

 

Edit: To add a little more information, the unassigned devices UI does allow me to add the SMB share and reports a success. But the "mount" button is greyed out and the logs don't seem to show any real attempt at making a connection (I have attached a screen shot of what the UI looks like).

 

 

Edited November 28, 20205 yr by JimJamUrUnraid

7 minutes ago, JimJamUrUnraid said:

Having an issue with a new SMB share that is in a remote location. All Windows machines can connect to the share without issue, unassigned devices cannot

My old SMB shares seem to be working just fine.

I have included my diagnostics files

 

diagnostics-20201127-1742.zip 169.39 kB · 0 downloads

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

1 minute ago, dlandon said:

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

There is a share called offsiteBackupDrive. I thought it was very strange that the logs didnt even show an attempt to mount the drive, but it also kinda makes sense because I cant click the mount button because it is greyed out.

2 minutes ago, JimJamUrUnraid said:

There is a share called offsiteBackupDrive. I thought it was very strange that the logs didnt even show an attempt to mount the drive, but it also kinda makes sense because I cant click the mount button because it is greyed out.

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.

Just now, dlandon said:

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.

Is there anyway around this? I dont want the server to be pingable.

1 minute ago, JimJamUrUnraid said:

Is there anyway around this? I dont want the server to be pingable.

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

Just now, dlandon said:

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

Dang, sounds like a new feature 😛. Thanks for your assistance.

1 minute ago, JimJamUrUnraid said:

Dang, sounds like a new feature 😛. Thanks for your assistance.

Set up a VPN.

Just now, dlandon said:

Set up a VPN.

This is across a VPN connection.

Just now, JimJamUrUnraid said:

This is across a VPN connection.

You should be good to go.

Just now, dlandon said:

You should be good to go.

I dont want internal probing attacks. Easiest way to find out about someone elses network.

6 hours ago, dlandon said:

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.

 

Note that your update to UD has created a mess for remote shares that were already mounted on my media unRAID. The shares lost their connection and report no size or use/free info after applying the update. I am unable to unmount them now so I will have to stop the array and/or restart to see if that will clear the issue. Alas I have a large transfer underway so the troubleshooting will have to wait.

 

On my backup unRAID I unmounted the remote shares BEFORE applying the update. Once the update was done I was able to re-mount. Your update script should have unmounted the shares before changing their mount location to /mnt/remotes.

 

I'll post diagnostics tomorrow if I'm unable to restore the remote shares after the array stop and/or reboot.

 

3 hours ago, AgentXXL said:

 

Note that your update to UD has created a mess for remote shares that were already mounted on my media unRAID. The shares lost their connection and report no size or use/free info after applying the update. I am unable to unmount them now so I will have to stop the array and/or restart to see if that will clear the issue. Alas I have a large transfer underway so the troubleshooting will have to wait.

 

On my backup unRAID I unmounted the remote shares BEFORE applying the update. Once the update was done I was able to re-mount. Your update script should have unmounted the shares before changing their mount location to /mnt/remotes.

 

I'll post diagnostics tomorrow if I'm unable to restore the remote shares after the array stop and/or reboot.

 

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.

3 hours ago, AgentXXL said:

 

Note that your update to UD has created a mess for remote shares that were already mounted on my media unRAID. The shares lost their connection and report no size or use/free info after applying the update. I am unable to unmount them now so I will have to stop the array and/or restart to see if that will clear the issue. Alas I have a large transfer underway so the troubleshooting will have to wait.

 

On my backup unRAID I unmounted the remote shares BEFORE applying the update. Once the update was done I was able to re-mount. Your update script should have unmounted the shares before changing their mount location to /mnt/remotes.

 

I'll post diagnostics tomorrow if I'm unable to restore the remote shares after the array stop and/or reboot.

 

Update UD again.  I'm limiting the change to version 6.9 and above.

3 hours ago, AgentXXL said:

Your update script should have unmounted the shares before changing their mount location to /mnt/remotes.

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.

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.

Edited November 28, 20205 yr by dlandon

In my opinion this change should not have been a forced update. There should be a migration path on a share by share basis and perhaps an additional tool to help identify any dependencies that are still pointing at the old share path that need updating.

 

This was sloppy and not called out enough in the release notes.

13 hours ago, JimJamUrUnraid said:

I dont want internal probing attacks. Easiest way to find out about someone elses network.

set your host's firewall to respond to ping only from the specific IP address in question.

51 minutes ago, sota said:

set your host's firewall to respond to ping only from the specific IP address in question.

That’s what I ended up doing. I still don’t like it. Yet another rule I have to manage. 

document, document, document.

 

reminds me: need get to my internal-use-only "forum" back up and running and migrate some notes/docs to it.