Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array


dlandon

Recommended Posts

5 minutes ago, itimpi said:

It would be interesting to know what data you think falls into that category as it is meant to be anonymised.

This is not about any particular file in itself. The whole set in itself is deanonymzing you 100%. Every setup described in that detail is unique. Some of the files would be sufficient to verify the dataset against a given setup, as e.g. the combination of hardware drive names in use.

 

Link to comment
6 minutes ago, dlandon said:

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

Sure, knock yourself out:

 

remotemount.thumb.png.5067a40bf442887f041e3d9c746664a8.png

 

The share is mountable on other machines, there are no additional firewall filters for the unraid host. The mount point name is the one generated by the plugin.

Edited by b0m541
Link to comment
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 by b0m541
Link to comment

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 by b0m541
Link to comment
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. :)

Link to comment

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.

  • Like 1
Link to comment

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 by JimJamUrUnraid
Link to comment
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.

Link to comment
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.

Link to comment
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.

 

Link to comment
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.

Link to comment
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.

Link to comment

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 by dlandon
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.