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


Recommended Posts

Thanks for your note.

 

The NVME devices are working flawless. So are 2 internal disks. The issue is contained to USB devices (and happens after changing the disk within the USB enclosure).


I don't think any of my mount points is called "disks". I think that's part of the issue with the plugin in my use case that makes this to display like that.

 

I will post a screenshot later.

Link to comment
7 minutes ago, steve1977 said:

The NVME devices are working flawless. So are 2 internal disks. The issue is contained to USB devices (and happens after changing the disk within the USB enclosure).

You said when you tried to run a SMART test, it said the disk was spun down.  That's what I addressed.

 

USB enclosures are a problem with UD because of the way they present the disk serial numbers to UD.  I'm not very hopeful that you can do what you want with the enclosure and UD.

Link to comment

Yes, thanks. All permanently installed / mounted disks work very well. This includes the NVME disks and also disks that are connected directly to the SATA adapters of my mobo.

 

USB works when starting up Unraid. However, if I turn off / detached the USB enclosure and put in another disks, things go crazy...

 

Below copy & paste from the GUI about disks sdx:

 

sdx nal_USB_3.0_[ID-removed]-4 TB--  

1TO_Exter_nal_USB_3.0MOUNT-0 B--  

2disksMOUNT-0 B--  

 

Both cannot be mounted.

Edited by steve1977
Link to comment

I have a quick (hopefully) question/issue. I'm sure I'm just missing something, but UD shows my array devices as... well... Unassigned devices... Screen shots included, and hopefully self explanatory. The sd* identification is different between the two, but as you can see the HDD ID is the same.

Array Diskss.jpg

UD Disks.jpg

Link to comment
2 hours ago, HSEDuster said:

I have a quick (hopefully) question/issue. I'm sure I'm just missing something, but UD shows my array devices as... well... Unassigned devices... Screen shots included, and hopefully self explanatory. The sd* identification is different between the two, but as you can see the HDD ID is the same.

Array Diskss.jpg

UD Disks.jpg

Post diagnostics.

Link to comment
11 minutes ago, HSEDuster said:

So I feel pretty dumb asking this, but which? I downloaded the diagnostics but I somewhat doubt you need/want all the various files. I am including the syslog but if there's another, I'll happily post it. 

syslog.txt 252.45 kB · 0 downloads

Post the complete diagnostics.zip.  I'm needing to see the vars so I can see how Unraid has assigned the disks.

Link to comment
2 hours ago, HSEDuster said:

So I feel pretty dumb asking this, but which? I downloaded the diagnostics but I somewhat doubt you need/want all the various files. I am including the syslog but if there's another, I'll happily post it. 

For future reference, please assume we want the complete zip. It has many things in it that can help make much more sense of things than just the syslog. I often don't even look at the syslog until I have looked at other things in diagnostics just to get some context of what I might be looking for in those hundreds of lines of syslog. And many things syslog doesn't even tell us that are in other parts of the diagnostics.

 

Save everyone time if we don't even have to ask for it. For example, it was 4 hours after your initial question before we finally got the diagnostics.

Link to comment
1 hour ago, HSEDuster said:

Oh okay, here you go then. Thank you very much.

tower-diagnostics-20201005-1609.zip 127.91 kB · 0 downloads

I'm not an expert with disk controllers, but it appears your disk controller caused Linux to have trouble assigning drive designations for Unraid and Unraid assigned the wrong designations to the array disks.  UD checks the vars for the disks not assigned to the array and designates any that are not as unassigned disks.  In this case all disks look to UD to be unassigned.

Oct  4 17:57:13 Tower emhttpd: Device inventory:
Oct  4 17:57:13 Tower emhttpd: HUS724020ALS641_P5GPZ54V (sdm) 512 3907029168
Oct  4 17:57:13 Tower emhttpd: device /dev/sdj problem getting id
Oct  4 17:57:13 Tower emhttpd: device /dev/sdk problem getting id
Oct  4 17:57:13 Tower emhttpd: device /dev/sdh problem getting id
Oct  4 17:57:13 Tower emhttpd: device /dev/sdg problem getting id
Oct  4 17:57:13 Tower emhttpd: device /dev/sdd problem getting id
Oct  4 17:57:13 Tower emhttpd: HUH72808CLAR8000_VJGT1S8X (sdt) 4096 1953506646
Oct  4 17:57:13 Tower emhttpd: device /dev/sde problem getting id
Oct  4 17:57:13 Tower emhttpd: KINGSTON_SA400S37120G_50026B768240E4F0 (sdb) 512 234441648
Oct  4 17:57:13 Tower emhttpd: HUS724040ALS640_PCKJBP8X (sdr) 512 7814037168
Oct  4 17:57:13 Tower emhttpd: device /dev/sdf problem getting id
Oct  4 17:57:13 Tower emhttpd: device /dev/sdc problem getting id
Oct  4 17:57:13 Tower emhttpd: HUS724040ALS640_PCJGNY0X (sds) 512 7814037168
Oct  4 17:57:13 Tower emhttpd: HUS724040ALS640_PCJGET8X (sdn) 512 7814037168
Oct  4 17:57:13 Tower emhttpd: HUS724040ALS640_PCKJMT2X (sdq) 512 7814037168
Oct  4 17:57:13 Tower emhttpd: HUH72808CLAR8000_VJGS29MX (sdo) 4096 1953506646
Oct  4 17:57:13 Tower emhttpd: HUS724020ALS641_P6JV08ZV (sdl) 512 3907029168
Oct  4 17:57:13 Tower emhttpd: device /dev/sdi problem getting id
Oct  4 17:57:13 Tower emhttpd: HUS724040ALS640_PCKJ6ZBX (sdp) 512 7814037168
Oct  4 17:57:13 Tower emhttpd: Kingston_DataTraveler_2.0_1C1B0D65F648B421496A204F-0:0 (sda) 512 30240768
Oct  4 17:57:13 Tower kernel: mdcmd (1): import 0 sdt 64 7814026532 0 HUH72808CLAR8000_VJGT1S8X
Oct  4 17:57:13 Tower kernel: md: import disk0: (sdt) HUH72808CLAR8000_VJGT1S8X size: 7814026532 
Oct  4 17:57:13 Tower kernel: mdcmd (2): import 1 sdr 64 3907018532 0 HUS724040ALS640_PCKJBP8X
Oct  4 17:57:13 Tower kernel: md: import disk1: (sdr) HUS724040ALS640_PCKJBP8X size: 3907018532 
Oct  4 17:57:13 Tower kernel: mdcmd (3): import 2 sds 64 3907018532 0 HUS724040ALS640_PCJGNY0X
Oct  4 17:57:13 Tower kernel: md: import disk2: (sds) HUS724040ALS640_PCJGNY0X size: 3907018532 
Oct  4 17:57:13 Tower kernel: mdcmd (4): import 3 sdq 64 3907018532 0 HUS724040ALS640_PCKJMT2X
Oct  4 17:57:13 Tower kernel: md: import disk3: (sdq) HUS724040ALS640_PCKJMT2X size: 3907018532 
Oct  4 17:57:13 Tower kernel: mdcmd (5): import 4 sdp 64 3907018532 0 HUS724040ALS640_PCKJ6ZBX
Oct  4 17:57:13 Tower kernel: md: import disk4: (sdp) HUS724040ALS640_PCKJ6ZBX size: 3907018532 
Oct  4 17:57:13 Tower kernel: mdcmd (6): import 5 sdn 64 3907018532 0 HUS724040ALS640_PCJGET8X
Oct  4 17:57:13 Tower kernel: md: import disk5: (sdn) HUS724040ALS640_PCJGET8X size: 3907018532 
Oct  4 17:57:13 Tower kernel: mdcmd (7): import 6 sdm 64 1953514552 0 HUS724020ALS641_P5GPZ54V
Oct  4 17:57:13 Tower kernel: md: import disk6: (sdm) HUS724020ALS641_P5GPZ54V size: 1953514552 
Oct  4 17:57:13 Tower kernel: mdcmd (8): import 7 sdl 64 1953514552 0 HUS724020ALS641_P6JV08ZV
Oct  4 17:57:13 Tower kernel: md: import disk7: (sdl) HUS724020ALS641_P6JV08ZV size: 1953514552 

This isn't really a UD issue.  UD is doing exactly what it is supposed to do.

 

I would report this in the 6.8.3 support forum.

Link to comment

An update on my two issues:

 

1) SMART test - SMART test only works with my one-bay enclosure. It does not work with my two-bay enclosure. This may be because of the enclosure rather than the UD script?

 

2) Mounting point - when I freshly boot Unraid, all works fine and the USB is well detected. However, when I turn off the USB, switch the disk and turn it back on, it no longer works. It has a proper mounting point at first. Upon changing the disk, the mounting point shows as "TO_Exter_nal_USB_3.0". I believe this can be fixed with XFS formatted disks by changing the UID in the settings. For NFS disks, there is no option to change it, which may be the cause of this issue?

Link to comment
21 hours ago, steve1977 said:

Yes, thanks. All permanently installed / mounted disks work very well. This includes the NVME disks and also disks that are connected directly to the SATA adapters of my mobo.

 

USB works when starting up Unraid. However, if I turn off / detached the USB enclosure and put in another disks, things go crazy...

 

Below copy & paste from the GUI about disks sdx:

 

sdx nal_USB_3.0_[ID-removed]-4 TB--  

1TO_Exter_nal_USB_3.0MOUNT-0 B--  

2disksMOUNT-0 B--  

 

Both cannot be mounted.

I can't help you with a text snippet from the UD page.  I asked for a screen shot of the UD page so I can see the file system type, the partitioning of the disks, and the other information shown on the complete UD page.

Edited by dlandon
Link to comment

I did a few more round of problem solving what is leading to what issue with various disks and enclosure. A few things I found out:

 

1) None of my multi-bay USB enclosures supports to run RAID. Only the single-bay enclosure supports it. I don't think that this issue is related to UD, but is more likely a broader Unraid issue (or even a hardware limitation?)

 

2) The UD issue does not occur after starting Unraid and freshly accessing the disks. It occurs once I unplug the USB enclosure and replace the disks within it. For example, I take out a 2TB disk and replace it instead with a 250GB disk. When I do this, the volume info does not get updated (i.e., 250GB is identified as 2TB disk after mounting). Also, the mount point has a different name rather than the actual mount name. Something like "TO_Exter_nal_USB_3.0". When I reboot Unraid, the mount name shows properly and also the volume info is correct. See below screenshot. The 250GB is wrongly identified as 2TB (previous disk had this volume) and you will also see the wrong mountain name. Both will be fixed when I restart Unraid.

 

1845391942_Capture-UDissue.thumb.PNG.c1ba2f329a95c22a3488470bbb1f09bd.PNG

Link to comment

After upgrading to 6.9.0-Beta29 none of my NFS shares will auto mount. Anyone else have this issue? I can post diagnostics if needed.

 

Additional Details

  1. I don't use USB or SMB related devices with with Unassigned Devices
  2. I can mount any of my NFS shares manually using the UD Mount button from the UI
  3. After boot they don't mount automatically, even with the Auto-Mount option enabled
Link to comment
54 minutes ago, ryanhaver said:

After upgrading to 6.9.0-Beta29 none of my NFS shares will auto mount. Anyone else have this issue? I can post diagnostics if needed.

Always post diagnostics.  How can we figure out what is wrong by just being told it doesn't work?

 

Please everyone, post your diagnostics each time you ask for help.  It's delays a resolution to your issue if we have to ask every time for diagnostics.  Support on the forum is mostly provided by volunteers like myself and it's not respectful of the time we donate to help.  Limetech has made the gathering of diagnostics very easy and obscures any private information so it is not exposed.  It's not difficult and goes a long way to providing the information needed to diagnose a problem.

Link to comment
26 minutes ago, ryanhaver said:

Attached are the affected unraid server's diagnostics.

unraid-diagnostics-20201006-1418.zip 138.66 kB · 1 download

This is the issue:

Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/Anime' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/TV Shows' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/docker' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/Movies' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/Workout' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/Music' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/Books' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/Video' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/transcode' cannot be mounted.
Oct  6 05:43:02 unRAID unassigned.devices: Remote SMB/NFS server '192.168.1.113' is offline and share '192.168.1.113:/volume2/Photo' cannot be mounted.

Because you can mount the NFS shares manually, the issue is that the Unraid network is not ready when the shares are auto mounted.  I try to have the auto mount of remote shares occur as late as possible in the startup process to give the network enough time to be ready, but in your case it is taking a bit longer.

Link to comment

I'm having issues passing through a 4tb hdd using UD to a VM. I've tried formatting the drive as NTFS using UD and Windows without luck. I'm only passing through 1 partition, but when I do, the VM detects multiple partitions. I've tried GPT, MBR and dynamic to no luck. I've also tried formatting in Windows then changing the 2nd vDisk location to partition 1 after.

 

The reason I need to pass through the partition only is because if I pass through the entire drive my dockers won't see new files. 

 

When I pass through the entire drive it works just fine.

 

image.thumb.png.0a504c79ebe73468ef51533e2fc2bdbf.png

 

I can click on Storage and navigate the directories using the web

image.png.71e55ab159e6f0b8c6a4b0f64138f675.png

 

 

/dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0FS4D-part1

image.png.2a8145fe93d2456e243f6303436bfab9.png

 

This is what it looks like in the VM

image.png.29caabe3fed0482a99b9ddf52bab810d.png

Edited by iPenguin02
Link to comment
On 10/4/2020 at 7:11 AM, dlandon said:

@Danno93093 supplied me with the diagnostics I needed to find and resolve the issue.  This is why I ask for the diagnostics.  I found an extra space character from some disks information in the df command that was causing a parsing problem.

 

Problem fixed in the latest release.

Can confirm -- it is now showing correctly on my server:
338510492_Image2020-10-06at11_24_29PM.thumb.png.01f005e8a67590ef11ddd964432dab84.png

Thanks @dlandon!

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.