On 12/27/2020 at 10:16 AM, dlandon said:

That shouldn't be a problem.

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.

 

 

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.

 

 

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

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 January 17, 20215 yr by DoItMyselfToo

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 January 16, 20215 yr by dlandon

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 January 17, 20215 yr by DoItMyselfToo

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.

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.

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.

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.

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 January 16, 20215 yr by vyreks

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 January 17, 20215 yr by DoItMyselfToo

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.

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)

 

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.

 

 

15 hours ago, dlandon said:

Post diagnostics.

I did, the diagnostics in my previous post to which you replied were the ones after changing the UUID manually and rebooting.

 

https://forums.unraid.net/topic/92462-unassigned-devices-managing-disk-drives-and-remote-shares-outside-of-the-unraid-array/?do=findComment&comment=935227

 

But here is a fresh set:

tower-diagnostics-20210116-1333.zip

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

 

 

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 January 16, 20215 yr by tstor

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.

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 January 19, 20215 yr by DoItMyselfToo

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.

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?

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.

58 minutes ago, dlandon said:

What version of Unraid?

6.9rc2

4 minutes ago, mikeyosm said:

6.9rc2

Unraid 6.9 takes over the disk spin down and any commands you issue for spin down will be removed.

35 minutes ago, dlandon said:

Unraid 6.9 takes over the disk spin down and any commands you issue for spin down will be removed.

OK, so 15 mins is the minimum then? I have a few external drives that are quite noisy and want them to spin down in 5 mins not 15. Possible?