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


dlandon

5983 posts in this topic Last Reply

Recommended Posts

3 hours ago, bobobeastie said:

Thanks, see attached.

Array Tab.jpg

I don't see anything that would keep the UD disk from mounting.  Reboot your server and start the array with the passphrase.  Don't do anything with the UD disk.  Let it mount on its own.  Once the array has started, wait about 5 minutes and post diagnostics.

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

19 hours ago, dlandon said:

I've seen this issue with 6.8 when permissions don't allow access to the share.  Not sure if it is Windows or the latest samba that blocks listing share contents.  Check your UD Settings and be sure the 'SMB Security' is set to allow access you desire.

Aight, I figured it out. Somehow, Unraid had -created- separate shares with my UD share labels, hence them being empty. I'll have to see if I configured a docker incorrectly, which has created unwanted shares before, or what, but for now it's fixed. Thanks for your help guys!

Link to post
42 minutes ago, dlandon said:

I don't see anything that would keep the UD disk from mounting.  Reboot your server and start the array with the passphrase.  Don't do anything with the UD disk.  Let it mount on its own.  Once the array has started, wait about 5 minutes and post diagnostics.

Diagnostics attached, post reboot without touching UD, and it isn't set to auto mount.

tower-diagnostics-20191103-2036.zip

Link to post
5 minutes ago, bobobeastie said:

Ok, now we are getting somewhere.

Nov  3 13:51:18 Tower unassigned.devices: Mount drive command: /sbin/mount  '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' '/mnt/disks/HGST_HDN726060ALE614_K1H90MAD'
Nov  3 13:51:18 Tower kernel: XFS (dm-10): Filesystem has duplicate UUID 196ad532-7693-46cf-ad40-13bdccc057cf - can't mount
Nov  3 13:51:18 Tower unassigned.devices: Mount of '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' failed. Error message: mount: /mnt/disks/HGST_HDN726060ALE614_K1H90MAD: wrong fs type, bad option, bad superblock on /dev/mapper/HGST_HDN726060ALE614_K1H90MAD, missing codepage or helper program, or other error. 
Nov  3 13:51:18 Tower unassigned.devices: Partition 'HGST_HDN726060ALE614_K1H90MAD' could not be mounted...

You have a disk problem.  I am not an expert on this type of error, maybe someone else can pipe in here and help.

 

I do potentially see an issue that I need to work on with UD.  Try to mount the drive once more and see if the log gives the message about the mapper file already exists.

Link to post

Nov 3 14:48:45 Tower unassigned.devices: Adding disk '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD'...
Nov 3 14:48:46 Tower unassigned.devices: luksOpen error: Device HGST_HDN726060ALE614_K1H90MAD already exists.
Nov 3 14:48:46 Tower unassigned.devices: Partition 'HGST_HDN726060ALE614_K1H90MAD' could not be mounted...

 

I was able to run some sort of filesystem check using the terminal, I think -L, it fixed some issues, after and I think beofre fixing it, I get this this when I use the web ui and I'm not sure what it means:

FS: crypto_LUKS

/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

fsck from util-linux 2.33.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

 

I used "/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD" from above to figure out which disk to tell it top check/fix.

Link to post
1 minute ago, bobobeastie said:

Nov 3 14:48:45 Tower unassigned.devices: Adding disk '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD'...
Nov 3 14:48:46 Tower unassigned.devices: luksOpen error: Device HGST_HDN726060ALE614_K1H90MAD already exists.
Nov 3 14:48:46 Tower unassigned.devices: Partition 'HGST_HDN726060ALE614_K1H90MAD' could not be mounted...

 

I was able to run some sort of filesystem check using the terminal, I think -L, it fixed some issues, after and I think beofre fixing it, I get this this when I use the web ui and I'm not sure what it means:

FS: crypto_LUKS

/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

fsck from util-linux 2.33.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

 

I used "/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD" from above to figure out which disk to tell it top check/fix.

UD has this built in.  Click the + sign by the serial number, then click on the four squares icon.

Link to post
50 minutes ago, dlandon said:

UD has this built in.  Click the + sign by the serial number, then click on the four squares icon.

I did that, that's what this part is from:

 

FS: crypto_LUKS

/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

fsck from util-linux 2.33.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

 

I'm guessing it didn't work.

Link to post
19 hours ago, johnnie.black said:

Try:


xfs_repair -v /dev/mapper/HGST_HDN726060ALE614_K1H90MAD

 

I see a problem here.  /dev/mapper doesn't exist because the disk has not been opened with luksopen.  I'll have to take a look.

Edited by dlandon
Link to post
On 11/3/2019 at 6:48 PM, bobobeastie said:

I did that, that's what this part is from:

 

FS: crypto_LUKS

/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

fsck from util-linux 2.33.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

 

I'm guessing it didn't work.

Update to the latest version of UD and then reboot.  You should see better handling of the encrypted disk when the mount fails, and the file system check should work properly now. 

Link to post
55 minutes ago, dlandon said:

Update to the latest version of UD and then reboot.  You should see better handling of the encrypted disk when the mount fails, and the file system check should work properly now. 

I was able to get it mounted and have files in lost+found, but only while in maintenance mode which might be normal.  Ideally I would be able to mount with the array mounted so I could transfer to the array.  I suspect the reason I can't mount it at the same time is a duplicate UUID, which I hear is due to something wrong with the file system, but it looks like a previous -L check worked based on the presence of the lost+found folder, although I do see this in the log:

 

Nov 5 04:31:41 Tower unassigned.devices: Mount of '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' failed. Error message: mount: /mnt/disks/HGST_HDN726060ALE614_K1H90MAD: wrong fs type, bad option, bad superblock on /dev/mapper/HGST_HDN726060ALE614_K1H90MAD, missing codepage or helper program, or other error.

 

I did try using UD built in check, but it didn't seem to do anything:

 

FS: crypto_LUKS

/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

fsck from util-linux 2.33.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

tower-diagnostics-20191105-1259.zip blkid.txt

Link to post
1 hour ago, bobobeastie said:

I was able to get it mounted and have files in lost+found, but only while in maintenance mode which might be normal.  Ideally I would be able to mount with the array mounted so I could transfer to the array.  I suspect the reason I can't mount it at the same time is a duplicate UUID, which I hear is due to something wrong with the file system, but it looks like a previous -L check worked based on the presence of the lost+found folder, although I do see this in the log:

 

Nov 5 04:31:41 Tower unassigned.devices: Mount of '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' failed. Error message: mount: /mnt/disks/HGST_HDN726060ALE614_K1H90MAD: wrong fs type, bad option, bad superblock on /dev/mapper/HGST_HDN726060ALE614_K1H90MAD, missing codepage or helper program, or other error.

 

I did try using UD built in check, but it didn't seem to do anything:

 

FS: crypto_LUKS

/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

fsck from util-linux 2.33.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

tower-diagnostics-20191105-1259.zip 110.44 kB · 0 downloads blkid.txt 3.13 kB · 0 downloads

Click on the button that says "Run with Correct Flag" to identify/fix file problems.  I see you already did that.  I see another issue I need to work on here.  It is not running xfs_repair.

Edited by dlandon
Link to post
1 hour ago, bobobeastie said:

I was able to get it mounted and have files in lost+found, but only while in maintenance mode which might be normal.  Ideally I would be able to mount with the array mounted so I could transfer to the array.  I suspect the reason I can't mount it at the same time is a duplicate UUID, which I hear is due to something wrong with the file system, but it looks like a previous -L check worked based on the presence of the lost+found folder, although I do see this in the log:

 

Nov 5 04:31:41 Tower unassigned.devices: Mount of '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' failed. Error message: mount: /mnt/disks/HGST_HDN726060ALE614_K1H90MAD: wrong fs type, bad option, bad superblock on /dev/mapper/HGST_HDN726060ALE614_K1H90MAD, missing codepage or helper program, or other error.

 

I did try using UD built in check, but it didn't seem to do anything:

 

FS: crypto_LUKS

/sbin/fsck /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

fsck from util-linux 2.33.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

tower-diagnostics-20191105-1259.zip 110.44 kB · 0 downloads blkid.txt 3.13 kB · 0 downloads

Update once more.  The file system check should be working now.

Link to post
3 minutes ago, dlandon said:

Update once more.  The file system check should be working now.

Thanks, it works now for me.  The drive will not mount while the array is started normally, xfs_repair through your tool was also ran with array mounted normally.  I think I already have the file in lost and found, so I'm going to work on verifying that and if there are any files I need I can transfer them while the array isn't mounted to a secondary location, and then back to the array.  However if it would help you make any changes I'd be more then happy to help test them in this situation, please let me know.  Perhaps it would be useful in your xfs_repair kicking off tool to be able to pass it different flags?

 

 

Log when I try to mount:

Nov 5 06:52:40 Tower unassigned.devices: Mount of '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' failed. Error message: mount: /mnt/disks/HGST_HDN726060ALE614_K1H90MAD: wrong fs type, bad option, bad superblock on /dev/mapper/HGST_HDN726060ALE614_K1H90MAD, missing codepage or helper program, or other error.

 

 

Your tool when I click on "Run with correct flag:

FS: crypto_LUKS

/sbin/xfs_repair /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 4
- agno = 6
- agno = 7
- agno = 2
- agno = 3
- agno = 8
- agno = 5
- agno = 9
- agno = 0
- agno = 1
- agno = 11
- agno = 10
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

Link to post
17 minutes ago, bobobeastie said:

Thanks, it works now for me.  The drive will not mount while the array is started normally, xfs_repair through your tool was also ran with array mounted normally.  I think I already have the file in lost and found, so I'm going to work on verifying that and if there are any files I need I can transfer them while the array isn't mounted to a secondary location, and then back to the array.  However if it would help you make any changes I'd be more then happy to help test them in this situation, please let me know.  Perhaps it would be useful in your xfs_repair kicking off tool to be able to pass it different flags?

 

 

Log when I try to mount:

Nov 5 06:52:40 Tower unassigned.devices: Mount of '/dev/mapper/HGST_HDN726060ALE614_K1H90MAD' failed. Error message: mount: /mnt/disks/HGST_HDN726060ALE614_K1H90MAD: wrong fs type, bad option, bad superblock on /dev/mapper/HGST_HDN726060ALE614_K1H90MAD, missing codepage or helper program, or other error.

 

 

Your tool when I click on "Run with correct flag:

FS: crypto_LUKS

/sbin/xfs_repair /dev/mapper/HGST_HDN726060ALE614_K1H90MAD 2>&1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 4
- agno = 6
- agno = 7
- agno = 2
- agno = 3
- agno = 8
- agno = 5
- agno = 9
- agno = 0
- agno = 1
- agno = 11
- agno = 10
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

There are others here that are more knowledgeable than I am on disk drive issues.  Maybe @johnnie.black can lend a hand.

Link to post
25 minutes ago, johnnie.black said:

xfs_repair looks normal, disk should mount normally.

Not sure if this should go in my thread, but could this just be due to a duplicate UUID?  I understand that that issue is usually caused by a bad file system, but now that that is fixed and the UUID issue remains, should it be addressed?  Even if I can get around it now, I'm guessing I might have the same issue when I'm done with the drive and will want to add it as a new drive to my array, so might as well try to deal with it now.  I could try running "xfs_admin -U generate /dev/mapper/mdX" on the array drive that is a duplicate of the UD drive, or probably better, try changing the UUID of the UD drive.

Link to post
19 minutes ago, bobobeastie said:

Not sure if this should go in my thread, but could this just be due to a duplicate UUID? 

No, if it was a duplicate UUID it would give that error, something like:

 

XFS: Filesystem xxx has duplicate UUID - can't mount

The current error is like there's no valid filesystem, and there is one since xfs_repair finds it, so possibly encryption related, i.e., it's not trying to mount the correct filesystem path

Link to post
1 hour ago, johnnie.black said:

No, if it was a duplicate UUID it would give that error, something like:

 


XFS: Filesystem xxx has duplicate UUID - can't mount

The current error is like there's no valid filesystem, and there is one since xfs_repair finds it, so possibly encryption related, i.e., it's not trying to mount the correct filesystem path

A few posts up he says the disk will mount when the array is not started,  but fails when the array is started because of a duplicate UUID.  A little history.  His disk was originally installed in the array, but now removed and he is now wanting UD to mount it so he can recover some files.  I'm not sure how he removed the disk from the array.

Edited by dlandon
Link to post
22 minutes ago, dlandon said:

A few posts up he says the disk will mount when the array is not started,  but fails when the array is started because of a duplicate UUID.  A little history.  His disk was originally installed in the array, but now removed and he is now wanting UD to mount it so he can recover some files.  I'm not sure how he removed the disk from the array.

The error on the log posted doesn't mention that, but if it's really a duplicate UUID problem he ca just change the UUID, but note that since the filesystem is encrypted it will need to be unlocked first.

 

xfs_admin -U generate /dev/mapper/device

 

Link to post
  • trurl pinned this topic

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.