3 hours ago, bobobeastie said:

Thanks, see attached.

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.

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!

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

1 hour ago, bobobeastie said:

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

tower-diagnostics-20191103-2036.zip 114.13 kB · 0 downloads

I wanted you to leave it auto mount to see if it would mount.

 

Try to mount it now.

5 minutes ago, dlandon said:

I wanted you to leave it auto mount to see if it would mount.

 

Try to mount it now.

Same boot after trying to mount.

tower-diagnostics-20191103-2152.zip

5 minutes ago, bobobeastie said:

Same boot after trying to mount.

tower-diagnostics-20191103-2152.zip 115.45 kB · 0 downloads

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.

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.

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.

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.

8 hours ago, bobobeastie said:

I'm guessing it didn't work.

Try:

xfs_repair -v /dev/mapper/HGST_HDN726060ALE614_K1H90MAD

 

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 November 5, 20196 yr by dlandon

I am trying to mount a share from my QNAP using unassigned devices. I keep getting an access denied error when connecting. I’m guessing it’s wanting the username and password for the share but I don’t know where to put that in? Any help would be awesome.

NFS or SMB?

 

There's a field right there when you add SMB share for username / password.  I don't use NFS so can't help you there.

Sorry, it’s NFS. I see the smb username and password options but no such thing for NFS

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. 

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

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 November 5, 20196 yr by dlandon

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.

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

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.

14 minutes ago, dlandon said:

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

xfs_repair looks normal, disk should mount normally.

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.

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

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 November 5, 20196 yr by dlandon

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