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


Recommended Posts

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

  • Thanks 1
Link to comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment

 

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