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


dlandon

5995 posts in this topic Last Reply

Recommended Posts

Not sure if anyone else has experienced this, but it's only happened over the last 2 weeks. I've been upgrading drives on my media unRAID, going from 10TB to 16TB. I then use the old 10TB drives to upgrade my backup unRAID. I leave the old 10TB drives alone until the parity rebuild completes successfully on the replacement 16TB drives.

 

Once the 16TB drives have been successfully rebuilt, I then want to run a preclear zero pass on the 10TB drives before re-using them in my backup unRAID. I know it's not really needed to successfully re-use the 10TB drives, but my OCD is better satisfied if I do. As my media unRAID is running on a 10+ year old motherboard/CPU, it only has USB 2.0 so I attach the old 10TB drives to an external USB 3.0 to SATA enclosure so I can run the zero pass on the backup unRAID system.

 

UD has no problem seeing the drive and shows it as XFS formatted. It can be mounted and the contents of the drive are accessible so everything appears to be working correctly. The only thing that I can't seem to do is enable the drive to be shared from its settings page in UD. Just like @vyreks mentioned, clicking Done or Save on the settings page reverts the Share switch to off. I only want to share it so I can do a quick contents compare over the network against the new 16TB drive that replaced it. As I can't get the drive to share, I temporarily put it back in the media unRAID, change the UUID, mount it and then do the quick contents compare with the new 16TB drive.

 

I then re-install it in the USB enclosure and re-attach it to the backup unRAID system via a USB3 port. I then attempt to remove the partition(s) so I can use preclear. For the last 2 x 10TB drives, for some reason UD fails when attempting to remove the partition. I tried changing the mountpoint label and that was successful, but it still failed when attempting to remove the partition. Rather than re-installing it in the media unRAID again, I tried attaching the 10TB drives to my Ubuntu laptop with USB 3 ports and using the Disks utility to remove the partition. It also fails, which seems to indicate that it's something to do with the formatting created when it was formally part of the protected unRAID array.

 

As a last ditch attempt before re-installing the 10TB drives in the media unRAID just to remove the partitions, I tried using my MacBook Pro and the Disk utility, with the 10TB drives still in the USB 3 enclosure. The Mac immediately reports the drive as unrecognized and asks me to 'Initialize' it, which I do. I can then erase the drive - typically I just choose to format it as NTFS as for some reason, Mac Disk Utility won't let you remove all partitions anymore. I can then re-attach the drive to my backup unRAID and now UD is able to remove the partition. And of course I can then run my preclear zero pass.

 

While trying to figure out both the share and remove partition issues, I tried some reboots. I made the mistake of forgetting to grab the logs before rebooting so I don't have any logs to share at this time. I have 2 more of the 10TB --> 16TB upgrades to do so I'll be sure to grab the logs if the same situation occurs. In any case, it seems that something changed in the way UD works when attempting to share or remove partitions. When I did this in the past going from 4TB to 10TB drives, it had no problems with either sharing or removing the partitions. I'm receiving the 16TB drives today so I'll see if the issue persists.

 

In any case, this long-winded post is more of a 'FYI' but I can confirm the same share issue that @vyreks posted above. Any thoughts until I can grab some diagnostics/logs if it happens again?

 

Link to post
  • Replies 6k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

New release of UD.  Changes: When changing the mount point (which is also the share name), the mount point is checked for a duplicate of a user share or another UD device.  Samba cannot handle

While I appreciate your interest in esthetics, there is more to consider than just 'aligning' disk drive mounts: This disk is mounted without a UD script, it is probably better to put it in th

Major new release of UD: "Where are the switches?"  The "Pass Through", "Read Only", "Automount", and "Share" switches have been moved to a new Edit Settings dialog.  This is also where the sc

Posted Images

4 hours ago, tstor said:

Thanks

 

Thanks again, I really appreciate the efforts you put into the UD plugins.

 

Now even though I have first changed the UUID via CLI and then rebooted the server, UD does not mount the encrypted disk. Any idea?

Post diagnostics.

Link to post
8 minutes ago, DoItMyselfToo said:

this disk continues to be a problem in UD.  ever since this issue, i cannot use this disk in UD.  it appears fine, then i copy files to it.  the disk then drops out, in, out, in, out, etc.  then some kind of error.  here is one i got today.

 

526016003_2021_01.15-UD_disk_issue.thumb.jpeg.cbb89c348fcfdeb4d08e5ca0e55b4775.jpeg
 

Post your diagnostics.  Where are you getting the /dev/sdam designation?  Are you using a port expander or drive bay?

Link to post
On 1/15/2021 at 3:18 PM, dlandon said:

Post your diagnostics.  Where are you getting the /dev/sdam designation?  Are you using a port expander or drive bay?

the drive is running off a 9201-16e via sas-to-sata breakout cables.  prior to this issue never had a problem.  a bunch of drives running off this controller now without any problems.  for some reason this drive in UD is a problem.  drive itself passes smart tests.

 

 

Edited by DoItMyselfToo
Link to post
3 hours ago, DoItMyselfToo said:

the drive is running off a 9201-16e via sas-to-sata breakout cables.  prior to this issue never had a problem.  a bunch of drives running off this controller now without any problems.  for some reason this drive in UD is a problem.  drive itself passes smart tests.

 

diagnostics-20210115-1519.zip 433.8 kB · 0 downloads

sdam is currently showing a duplicate UUID.  You'll need to go to UD settings and change the UUID so it will mount.

Edited by dlandon
Link to post
On 1/15/2021 at 3:55 PM, dlandon said:

sdam is currently showing a duplicate UUID.  You'll need to go to D settings and change the UUID so it will mount.

how can i figure out what is causing the mount points to duplicate?  i just deleted the mount point and reformatted the disk.  the same mount point returns.

 

Edited by DoItMyselfToo
Link to post
Just now, DoItMyselfToo said:

how can i figure out what is causing the mount points to duplicate?  i just deleted the mount point and reformatted the disk.  the same mount point returns.

UD will use the same mount point for the disk when it is reformatted.  You can change the mount point.  The issue is the UUID.  Go to the UD settings and change the UUID.

Link to post
On 1/14/2021 at 7:08 PM, bidmead said:

I'm not sure I see how that improves the security. And what if—as in my case—the array is unencrypted?

 

-- 

Chris

You have several options:

  • Upgrade to 6.9 and put the disk in the pool.  The encryption will work on that drive just like array disks,
  • Set the password in UD settings, mount the disk, then go back to UD settings and blank the password.
  • Provide the key file and then delete it once the UD disk has mounted.

The UD encryption feature was to allow a disk removed from the array to be mounted and data removed as necessary.  I'm not sure of your use case, but for what you want, the array encryption is probably a better answer.

 

You do understand that a person needs multiple pieces of the server to be able to access the encrypted disk?  Just having the physical disk is useless.  If someone takes your whole server, to access your one encrypted disk, you probably have bigger problems.

Link to post
5 hours ago, AgentXXL said:

The only thing that I can't seem to do is enable the drive to be shared from its settings page in UD.

When the share switch is turned on it shows properly in the tool tip.  It is not showing properly in the Edit Settings page.  This will be fixed in the next release.

Link to post
4 hours ago, dlandon said:

UD will use the same mount point for the disk when it is reformatted.  You can change the mount point.  The issue is the UUID.  Go to the UD settings and change the UUID.

changed the UUID in UD.  and did a little bit of reading up on this.  post if more issues.  thank you.

Link to post
5 hours ago, dlandon said:

Please show a screen shot.

Here's screen record showing the issue https://streamable.com/ya6du0

I posted here because today i was trying to set up smb_extra.conf to allow for custom share in addition to normal one given by the UD plugin, after restarting the array i noticed the custom share appeared but the main UD share disappeared. Then i noticed that the share button is not sticking.

 

I did some troubleshooting, removed the custom share, rebooted few times, unfortunately main share didn't come back. When i was mounting the drive with UD i could see in the log that the share was being created but it wasn't accessible via SMB. Then i gave up and posted here. I checked few hours later and saw that the main UD share was accessible but the button still is not sticking so i recorded this video.

 

tower-diagnostics-20210116-0343.zip

Edited by vyreks
Link to post
On 1/15/2021 at 4:18 PM, dlandon said:

UD will use the same mount point for the disk when it is reformatted.  You can change the mount point.  The issue is the UUID.  Go to the UD settings and change the UUID.

test copied 50 gigs to this disk.  errored out.

 

 

Edited by DoItMyselfToo
Link to post
7 hours ago, vyreks said:

Then i noticed that the share button is not sticking.

It is sticking, but the Edit Settings does not show it correctly.  It is fixed in the next release.  For the moment, hover your mouse over the edit settings icon and that will display the correct shares status.

 

7 hours ago, vyreks said:

I checked few hours later and saw that the main UD share was accessible but the button still is not sticking so i recorded this video.

When UD sets up a SMB share, it can take a few minutes before the share shows up.  It is not necessarily immediate.

 

Be careful when making changes to the smb-extras.cfg file.  It's easy to break things.

Link to post
6 hours ago, DoItMyselfToo said:

test copied 50 gigs to this disk.  errored out.

 

diagnostics-20210115-2111.zip 443.97 kB · 0 downloads

You are having disk issues that need to be fixed:

Jan 15 21:08:02 unCube kernel: print_req_error: I/O error, dev sdam, sector 22319448
Jan 15 21:08:02 unCube kernel: sd 10:0:12:0: [sdam] tag#5046 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Jan 15 21:08:02 unCube kernel: sd 10:0:12:0: [sdam] tag#5046 Sense Key : 0x2 [current] 
Jan 15 21:08:02 unCube kernel: sd 10:0:12:0: [sdam] tag#5046 ASC=0x4 ASCQ=0x0 
Jan 15 21:08:02 unCube kernel: sd 10:0:12:0: [sdam] tag#5046 CDB: opcode=0x8a 8a 00 00 00 00 00 01 54 95 60 00 00 03 f8 00 00
Jan 15 21:08:02 unCube kernel: print_req_error: I/O error, dev sdam, sector 22320480
Jan 15 21:08:02 unCube kernel: xfs_destroy_ioend: 502 callbacks suppressed
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 22288728
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 23271504
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 23361616
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 23451728
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 23541840
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 23601264
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 23846368
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 24492552
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 24874048
Jan 15 21:08:02 unCube kernel: XFS (sdam1): writeback error on sector 26049528
Jan 15 21:08:12 unCube kernel: scsi_io_completion_action: 5387 callbacks suppressed
Jan 15 21:08:12 unCube kernel: sd 10:0:12:0: [sdam] tag#4334 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Jan 15 21:08:12 unCube kernel: sd 10:0:12:0: [sdam] tag#4334 Sense Key : 0x2 [current] 
Jan 15 21:08:12 unCube kernel: sd 10:0:12:0: [sdam] tag#4334 ASC=0x4 ASCQ=0x0 
Jan 15 21:08:12 unCube kernel: sd 10:0:12:0: [sdam] tag#4334 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
Jan 15 21:08:12 unCube kernel: print_req_error: 5387 callbacks suppressed
Jan 15 21:08:12 unCube kernel: print_req_error: I/O error, dev sdam, sector 3907018936
Jan 15 21:08:12 unCube kernel: sd 10:0:12:0: [sdam] tag#1785 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Jan 15 21:08:12 unCube kernel: sd 10:0:12:0: [sdam] tag#1785 Sense Key : 0x2 [current] 
Jan 15 21:08:12 unCube kernel: sd 10:0:12:0: [sdam] tag#1785 ASC=0x4 ASCQ=0x0 
Jan 15 21:08:12 unCube kernel: sd 10:0:12:0: [sdam] tag#1785 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 00 c0 00 00 00 40 00 00
Jan 15 21:08:12 unCube kernel: print_req_error: I/O error, dev sdam, sector 192
Jan 15 21:08:12 unCube kernel: XFS (sdam1): metadata I/O error in "xlog_iodone" at daddr 0xe8e06078 len 64 error 5
Jan 15 21:08:12 unCube kernel: XFS (sdam1): xfs_do_force_shutdown(0x2) called from line 1271 of file fs/xfs/xfs_log.c.  Return address = 000000004922461f
Jan 15 21:08:12 unCube kernel: XFS (sdam1): Log I/O Error Detected.  Shutting down filesystem
Jan 15 21:08:12 unCube kernel: XFS (sdam1): Please umount the filesystem and rectify the problem(s)

 

Link to post
7 hours ago, DoItMyselfToo said:

test copied 50 gigs to this disk.  errored out.

One thing would should do is to update the 16 port LSI firmware, might not be the problem but all p20 releases except the latest one (20.00.07.00) have known issues, if that doesn't help swap cables/slot with another disk.

 

You can do the update using Unraid.

 

 

Link to post
3 minutes ago, tstor said:

after changing the UUID manually and rebooting.

It's still showing as having a duplicate UUID:

 

Jan 15 02:04:51 Tower kernel: XFS (dm-13): Filesystem has duplicate UUID 601cb298-100f-4990-b3ca-347bd2225192 - can't mount

 

Link to post

 

1 hour ago, JorgeB said:

It's still showing as having a duplicate UUID

 

 

blkid did not show any duplicate UUIDs. I changed the duplicate UUID of the encrypted partition with "cryptsetup luksUUID...", but I didn't think about the XFS file system becoming visible once the encrypted partition is unlocked. So here is write-up of what I did ultimately to get access in case someone else gets into the same situation

 

Goal: Access an encrypted drive taken out of the array in UD on the same system.

Issue: If this was due to a swap and the drive taken out has been reconstructed, there will be UUID conflicts that prevent mounting. This is because the reconstructed drive is a true clone including UUIDs. So one needs to change the UUIDs of the drive no longer being in the array. In my case the UD drive is /dev/sdv

 

First generate two new UUIDs

root@Tower:/mnt# uuidgen
2284b0b6-eead-4d1c-adf0-58efb36085e2
root@Tower:/mnt# uuidgen
980b09f3-ced6-4fc4-8875-f94086100f39

 

Use the first one with luksUUID command to change the first conflicting UUID

 

root@Tower:~# cryptsetup luksUUID --uuid=2284b0b6-eead-4d1c-adf0-58efb36085e2 /dev/sdv1

WARNING!
========
Do you really want to change UUID of device?

Are you sure? (Type 'yes' in capital letters): YES


Now the encrypted partition needs to be unlocked in order to get access at the XFS file system UUID that also needs to be changed using the second UUID generated above.

 

root@Tower:/mnt# /usr/sbin/cryptsetup --verbose luksOpen /dev/sdt1 UAdisklabel
Enter passphrase for /dev/sdt1: 
Key slot 0 unlocked.
Command successful.
root@Tower:/mnt# ls /dev/mapper/
control  md10@  md11@  md12@  md13@  md14@  md2@  md3@  md4@  md5@  md6@  md7@  md8@  md9@  UAdisklabel@

root@Tower:/mnt# xfs_admin -U 980b09f3-ced6-4fc4-8875-f94086100f39  /dev/mapper/UAdisklabel 
Clearing log and setting UUID
writing all SBs
new UUID = 980b09f3-ced6-4fc4-8875-f94086100f39

 

In order to allow mounting via UD, I used the same label ("UAdisklabel") as UD uses for that drive.

Helpful additional commands:

 

blkid
cryptsetup luksUUID /dev/sdv1
xfs_admin -lu /dev/mapper/UAdisklabel

 

blkid lists the UUIDs visible for the system. Initially it does not show the XFS file system UUID because that one is not yet accessible.

luksUUID displays the UUID of the encrypted partition

xfs_admin shows the UUID of the unmounted XFS partition after unlocking

 

Now I can mount the previous array drive in UD and access / change its content.

 

I hope it helps and if someone with deeper knowledge would do a sanity check of what I wrote, it would not hurt.

Edited by tstor
Link to post

My disks are using UNRAID default spin down delay of 15mins and not the delay that i've set using UD script.

My script looks like this...

 

esac
sudo hdparm -S10 $DEVICE

 

This used to work in the older version of UNRAID and UD plugin but now it's not.

Link to post
On 1/16/2021 at 4:22 AM, JorgeB said:

One thing would should do is to update the 16 port LSI firmware, might not be the problem but all p20 releases except the latest one (20.00.07.00) have known issues, if that doesn't help swap cables/slot with another disk.

 

You can do the update using Unraid.

 

 

thank you for offering your input.  i appreciate this.

 

i always update all sas controllers to the latest (20.00.07.00) firmware before running in my server.  the cables are new.  still problems with this disk as an UD.  but i am currently preclearing this disk.  did a full read of the disk and now at 20% zeroing without any hardware change.

 

update:  the disk pre-cleared without issues.  but i did double check the firmware on my two LSI SAS HBA's.  the 8i was updated to the latest (20.00.07.00) but the 16e was not (20.00.06.00).  my bad.  not sure how i missed that.  but thank you again to @JorgeB for their post.

Edited by DoItMyselfToo
Link to post
3 hours ago, tstor said:

 

 

 

blkid did not show any duplicate UUIDs. I changed the duplicate UUID of the encrypted partition with "cryptsetup luksUUID...", but I didn't think about the XFS file system becoming visible once the encrypted partition is unlocked. So here is write-up of what I did ultimately to get access in case someone else gets into the same situation

 

Goal: Access an encrypted drive taken out of the array in UD on the same system.

Issue: If this was due to a swap and the drive taken out has been reconstructed, there will be UUID conflicts that prevent mounting. This is because the reconstructed drive is a true clone including UUIDs. So one needs to change the UUIDs of the drive no longer being in the array. In my case the UD drive is /dev/sdv

 

First generate two new UUIDs


root@Tower:/mnt# uuidgen
2284b0b6-eead-4d1c-adf0-58efb36085e2
root@Tower:/mnt# uuidgen
980b09f3-ced6-4fc4-8875-f94086100f39

 

Use the first one with luksUUID command to change the first conflicting UUID

 


root@Tower:~# cryptsetup luksUUID --uuid=2284b0b6-eead-4d1c-adf0-58efb36085e2 /dev/sdv1

WARNING!
========
Do you really want to change UUID of device?

Are you sure? (Type 'yes' in capital letters): YES


Now the encrypted partition needs to be unlocked in order to get access at the XFS file system UUID that also needs to be changed using the second UUID generated above.

 


root@Tower:/mnt# /usr/sbin/cryptsetup --verbose luksOpen /dev/sdt1 UAdisklabel
Enter passphrase for /dev/sdt1: 
Key slot 0 unlocked.
Command successful.
root@Tower:/mnt# ls /dev/mapper/
control  md10@  md11@  md12@  md13@  md14@  md2@  md3@  md4@  md5@  md6@  md7@  md8@  md9@  UAdisklabel@

root@Tower:/mnt# xfs_admin -U 980b09f3-ced6-4fc4-8875-f94086100f39  /dev/mapper/UAdisklabel 
Clearing log and setting UUID
writing all SBs
new UUID = 980b09f3-ced6-4fc4-8875-f94086100f39

 

In order to allow mounting via UD, I used the same label ("UAdisklabel") as UD uses for that drive.

Helpful additional commands:

 


blkid
cryptsetup luksUUID /dev/sdv1
xfs_admin -lu /dev/mapper/UAdisklabel

 

blkid lists the UUIDs visible for the system. Initially it does not show the XFS file system UUID because that one is not yet accessible.

luksUUID displays the UUID of the encrypted partition

xfs_admin shows the UUID of the unmounted XFS partition after unlocking

 

Now I can mount the previous array drive in UD and access / change its content.

 

I hope it helps and if someone with deeper knowledge would do a sanity check of what I wrote, it would not hurt.

I'm going to issue a new release today that will implement the change of UUID on an encrypted disk.

Link to post
3 hours ago, mikeyosm said:

My disks are using UNRAID default spin down delay of 15mins and not the delay that i've set using UD script.

My script looks like this...

 

esac
sudo hdparm -S10 $DEVICE

 

This used to work in the older version of UNRAID and UD plugin but now it's not.

What version of Unraid?

Link to post
31 minutes ago, DoItMyselfToo said:

still problems with this disk as an UD.

UD mounts and unmounts disks.  It does not have anything to do with read/write operations.

Link to post

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.