SOLVED CRITICAL: The following multipaths are not optimal: disk1

[Andreas Ideler]

CRITICAL: The following multipaths are not optimal: disk1

The Disk1 works put today come this messages in Freenas Interface CRITICAL: The following multipaths are not optimal: disk1 ( i can not Import other Automatik Importen :()

I can not using Disk 1 but one this disk importen data :( Please helpe me Fore Searching this Problem Pleas.

Sorrye my englisch is not good i German speaking in my Country ;)

 

[William Grzybowski]

Do you really have multipath working in your system?

Otherwise it is a bug that I cannot solve your hardware access.

 

[Andreas Ideler]

Ka 2 cpu cores and 4 I have a hard drive where unfortunately these errors since latest FreeNAS can also reinstall Works but unfortunately still does not: (

Please Helpe me :( Please say not Reformatet is the only way for this Problem :(:( Werye Importen data from me Pictures from 1997 - Today and Life stoff la Bewerbungs mappen ectra please help me

I'm totally desperate

 

[William Grzybowski]

Sorry I cant help you, communication is a barrier.

 

[Andreas Ideler]

Habe mal die platte ab gesteckt und wieder angesteckt kommt immer das Hier:

Feb 1 16:30:37 freenas kernel: GEOM_MULTIPATH: disk1 created
Feb 1 16:30:37 freenas kernel: GEOM_MULTIPATH: ada4 added to disk1
Feb 1 16:30:37 freenas kernel: GEOM_MULTIPATH: ada4 is now active path in disk1
Feb 1 16:30:37 freenas kernel: GEOM: multipath/disk1: corrupt or invalid GPT detected.
Feb 1 16:30:37 freenas kernel: GEOM: multipath/disk1: GPT rejected -- may not be recoverable.

Stop refresh


hielft das zur fehler behebung`?

 

[LostFate]

Well, I can help the language barrier (as I am having the same issue as him), hopefully someone can help me. Basically, The south bridge in my NAS decided to completely crap the bed on me. The system would boot from USB but I had no disks. Disks are visible in another system. When you put the disks in another system and fire up FreeNAS you are greeted with this rather wonderful message:

GEOM_MULTIPATH: disk1 created
GEOM_MULTIPATH: ada0 added to disk1
GEOM_MULTIPATH: ada0 is now active path in disk1
GEOM: multipath/disk1: corrupt or invalid GPT detected.
GEOM: multipath/disk1: GPT rejected -- may not be recoverable.

From what I can tell, the system screwed up the GPT tables and FreeNAS no longer knows what is going on with the drive (certainly wasn't in a multipath environment, ever). The other disk in my stripe (yep... I'm an idiot) is visible and throws no errors. FreeNAS can even see that a storage pool exists as long as the second disk is in the system. The data on my drives is considered extremely important (some critical... yes... I know I'm an idiot... I couldn't afford the drop in storage space and the performance gain didn't hurt either). Here's the part where you tell me I'm completely boned and I beg you to help walk me through scraping any data off my disks by any means. At very very least, I'd like to recover my tiny XML file with my legitimate Windows serials... It's a serious kick in the nuts to lose legitimate serial numbers.

I'm willing and able to provide any information you need. Just ask and maybe walk me through t if it's something way out there. I do have network administration background so pointing me in the right direction may be all I need. Thank you a whole ton, ahead of time!

 

[mav@]

I guess for some reason your setup was identified as multipath. To solve present situation you may try to destroy multipath instance first with `gmultipath destroy disk1` and then recover secondary GPT partition table on disk overwritten by gmultipath with `gpart recover adaX`. Though it doesn't explain how have you got into this situation.

 

[cyberjock]

LostFate,

I'd say you are completely boned unfortunately. :(

One thing I never get is that people that choose to stripe almost always have the same complaint.. "couldn't afford the cost of the extra drive, couldn't afford the performance penalty, hardware couldn't handle the parity calculations". Do you have any idea how expensive it is to do data recovery? Think 5 figures for the chance to ... So I'd say if you had gone with a RAIDZ1 you would have saved yourself a big discount on data recovery. :P

 

[LostFate]

Sorry I disappeared forever... I'm in the middle of a move on top of everything else. I just had a brilliant idea that I'd like to run past you all before going forward. Now if the partition table is screwed and I'm likely to lose my partition layout by deleting it, I will lose data correct? So now here is my idea, and again correct me if I'm wrong, I have 2 identical drives (Make, Model, Size, Firmware, possibly even batch though they are in a cage so I can't look at that right now) in a stripe. In an ideal world, they will have identical partition tables correct? Can I dd the partition table from the good drive to the other and have any hope of recovering any of my data? Barring that, because these are unencrypted drives, is there anyway I could scrape the raw data off the disk onto another disk? I realize that it won't be easy (love me a challenge anyways) and I'm aware that because it's split between drives it'll be that much harder to piece together but I do have a lot of data that I'd rather not lose. I refuse to believe that the corruption is systemic. The drive was well within SMART parameters and never threw a flag, is in a relatively safe and stable environment, was giving me no performance or preliminary data corruption issues. Obviously something has to be wrong but the logical conclusion is that the motherboard died and there is no way the chipset had enough time to write over even 20% of my disk (in the event it started writing garbage data).

 

[mav@]

Now if the partition table is screwed and I'm likely to lose my partition layout by deleting it

Have you seen my post? multipath could corrupt second copy of GPT at the disk end, but not the first one at the beginning. First one was not used probably just because multipath metadata reduced disk size by one sector, confusing GPT code. If you destroy multipath as I have proposed, you may get your partition access back and I don't expect complications from that.

 

[LostFate]

Alright, I did go ahead and delete the multipath. You were right and I did gain access to my drive again, however, I'm now being tossed errors that it can not create my mount points (/Storage/Users... etc...).

[root@freenas] ~# zpool import -Ff Storage
cannot mount '/Storage': failed to create mountpoint
cannot mount '/Storage/Users': failed to create mountpoint
cannot mount '/Storage/Vaults': failed to create mountpoint
cannot mount '/Storage/Vaults/Nates_Steam': failed to create mountpoint
cannot mount '/Storage/jail': failed to create mountpoint
cannot mount '/Storage/media': failed to create mountpoint
cannot mount '/Storage/plugins': failed to create mountpoint
cannot mount '/Storage/tftp': failed to create mountpoint

I'm going to initiate a scrub in the interim.

 

[jkh]

Sorrye my englisch is not good i German speaking in my Country ;)

Deutsche nicht ein grosses problem ist, aber mit ihrem systemefehler bin Ich leider nicht so sicher. :( Das sehr merkwürdig ist. Haben Sie irgendwas in die configuration vorher geändert, oder hast das fehlermeldung zum ersten Mal ohne warnung erscheint? Sie können auch vielleicht die multipath einfach erlöschen - diese Methode hast für "LostFate" hoffentlich geklappt!

 

[LostFate]

*facepalm*... Active Directory... I may not have mount permissions anymore. Let me attempt a CHMOD.

Edit: No initial mount point to CHMOD. Going to try the long arduous journey of re-setting up my AD. Any new ideas are extremely welcome.

 

[LostFate]

Alright, update... Crisis averted! I'd like to thank you all. I was pretty sure I was going to have to cry myself to sleep for 4TB of data worth of nights.

Steps to fix this problem:
Step 1) If your system is fine (isn't the reason for the corruption) then don't move systems.
Step 2) "gmultipath destroy 'x'" - While substituting x for whatever you are being prompted with in the console. This will at least get your drives recognized.
Step 3) "zpool import -Ff 'x'" - While substituting x for your ZFS Pool. With any luck (if you managed to accomplish step 1), you will be presented with your data. If not, you will likely be prompted with a lovely message stating your mountpoints are invalid... BUT AT LEAST IT'S SEEING WHAT THE MOUNTPOINTS SHOULD BE! 8D A step in the right direction if I say so.

If you couldn't accomplish step 1 (as is my case), do the following:
Step 4) "zfs allow -s @permset1 create,mount,snapshot,clone,promote 'x'" - "x" being your ZFS Pool. This will set up a permissions rule that you will attach to users in the next step.
Step 5) "zfs allow root @permset1 'x'" - "x" being your ZFS Pool. This will give the permissions set in step 4 to root.
Step 6) "zpool export 'x'" - "x" being your ZFS Pool. Release the pool so we can re-import it with the new permissions.
Step 7) *Disclaimer: I used the GUI's auto-import feature for this step but I imagine that the command line tool would work largely the same.* Re-import your volume.

That should be all she wrote. You should have access to your data again.

Due to the nature of this problem, I HIGHLY recommend doing a scrub on your volume.
Step 8) "zpool scrub 'x'" - "x" being your ZFS Pool.

 

[ccdanieldb]

Hello. I am new to FreeNAS and I think this post will solve my similar multi-path problem. My question is about step 2 above. What should go in place of "x". I have 8 drives and 7 of them are now being looked at as multipaths (photo attached). Do i replace x with multipath/disk3 or ada14 or both.

Thanks for your help.

 

[ccdanieldb]

Solved. It is disk. i.e. gmultipath destroy disk3. I have access now. I had to destroy all multipaths then restart a few times before i could get the import to take. Thank you very much LostFate. I also want to add that this happened when i decided to change my connection for my two external 4 bay hard drive enclosure from esata to USB3.0. Be aware that this change can caused this multipath problem.

 

[LostFate]

Oh geez! I posted this ages ago! Glad to hear it all worked out though. This was an excellent fix and I had to use it a couple times over the years.

 

[Paul Boesshar]

Hi,

i have the same issue. I am using FreeNAS 9.10 . My NAS has 4 internal HDDs which work just fine but since the update tu 9.xx i have issues with external JBOD Cases via USB3.0.
Each Casing holds 5 Disks and since one of the Upgrades FreeNAS is not amused with the Multipath Issue just like written above.

The output states that (in my case) the disks 1-4 are nt optimal. gmultipath destroy diskxx works fine (after that i am able to Import the Pool ) and even a gpart recover works. One reboot later the same again. Disks 1-4 bla bla . . . .
Has anyone a permanent solution for this issue? I have this issue simultaniously with 2 external enclosures (same Model) with each 5 Disks.

i looked for solutions everywhere but the tipps in this forum were the only ones that helped at least for accessing my data again. Is there any possibility to see what multipath was expecting in the gpt to correct the issue? Any help. This would be a nice Feature for later Versions of freenas to auto-korrekt something like this error.

If nothing helps i will copy everything to a freshly build Pool without the Problem. But 12TB of date take about 24-48h

 

[mav@]

My NAS has 4 internal HDDs which work just fine but since the update tu 9.xx i have issues with external JBOD Cases via USB3.0.

USB devices quite often violate SCSI specifications. In particular, they often report non-unique driver serial numbers, etc., that confuses FreeNAS multipath logic. This logic was slightly improved recently to handle cases that are not formally illegal. So you may try to update to 9.10.1-U4 when it released nearest time and see if you are lucky.

 

[Paul Boesshar]

Hi, today the U4 update was available and Tadaaaa my issue is gone. No errors, Zpool import available, no GPT error messages.
I have to say i am impressed. I work with freeNAS since 8.xx and am so grateful for this ready to go distri. This was the first time i ever encounterd Problems i couldn´t solve on my own.
The speed with wich i got an answer is remarkable.
I work at an lokal ISP as an VMWare Expert and System Engineer and even the expensive SAN an NAS Systems i use are not that flexible like FreeNAS and their support oftens needs a longer response time :)
I think i am going to donate Money in return for using freenas.