hello again in some files I am geting the error

cp: error reading '/temp/domains/hassio/haos_ova-9.3.vmdk': Input/output error

is there a solution ?

15 hours ago, Server_home said:

cp: error reading '/temp/domains/hassio/haos_ova-9.3.vmdk': Input/output error

is there a solution ?

Post new diags after trying to copy one of those files.

5 minutes ago, JorgeB said:

Post new diags after trying to copy one of those files.

I didn't understand what you mean. Can you please explain?

After getting that error download and post new diagnostics.

Hey team,

 

Having same issue with my cache drive. Had some RAM issues that caused random crashs (which the RAM is now replaced after checking memtest).

 

Cache is sayin "Unmountable: Unsupported or no file system", I've attached diag files.

explodingkitten-diagnostics-20240106-1701.zip

Check filesystem on cache, run it without -n.

1 hour ago, JorgeB said:

Check filesystem on cache, run it without -n.

 

Couldn't run it via the GUI as it didn't have the option for the cache drive. Ran it via the CLI and got the following...

 

xfs_repair /dev/nvme0n1
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...

....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

 

Sorry, could not find valid secondary superblock Exiting now.

18 minutes ago, mrderrickc said:

Couldn't run it via the GUI as it didn't have the option for the cache drive.

It should have.

 

18 minutes ago, mrderrickc said:

Ran it via the CLI and got the following...

That's not correct, type:

 

xfs_repair /dev/nvme0n1p1

 

20 minutes ago, JorgeB said:

It should have.

 

That's not correct, type:

 

xfs_repair /dev/nvme0n1p1

 

 

This is what is shows in the GUI.

 

 

Ran the above code and got this.

 

xfs_repair /dev/nvme0n1p1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

You should now run without -n and adding -L.  A mount has already failed by this point. 

8 minutes ago, mrderrickc said:

This is what is shows in the GUI.

Filesystem is set to auto, you must set it to xfs to use the GUI.

3 minutes ago, JorgeB said:

Filesystem is set to auto, you must set it to xfs to use the GUI.

 

Thanks! That seems to have done the trick!

Hello there, I would like to attach exact same problem of my friends small server.

 

trying to format doesn't work. What should he try to do in this situation?

tower-diagnostics-20240201-1239.zip

2 minutes ago, rogales said:

trying to format doesn't work. What should he try to do in this situation?

Formatting will delete all data, device is reporting busy, reboot and it should then format.

Edit: I decided to create a new thread instead, as this one is marked as solved. 

 

 

Hello, I am having the same problem where by cache drive is "unmountable", file system was btrfs. I tried running some of the commands that you recommended in this thread but I only got this as a response. This problem appeared out of nowhere.

 

 

Tower Diagnostics 20240204 2135.zip

Edited February 4, 20242 yr by tomas.
new thread

@JorgeB can you take a look at my diagnostics file?  It looks like you've had success helping others ... now I need help too  

8 hours ago, 2112 said:

@JorgeB can you take a look at my diagnostics file?

And where are they? And what is the problem?

1 hour ago, JorgeB said:

And where are they? And what is the problem?

 

My cache drives are showing up as "unmountable:  unsupported or no file system."  I am unable to stop/start my array and assign these drives but the highlighted message below keeps showing.  Unraid will let me format these but I don't want to lose my appdata contents.  Any help or guidance would be appreciated.

 

 

Edited February 5, 20242 yr by 2112

Try clearing the log tree, if that is the only problem it may fix it:

 

btrfs rescue zero-log /dev/sdh1

 

Then restart the array.

12 minutes ago, JorgeB said:

Try clearing the log tree, if that is the only problem it may fix it:

 

btrfs rescue zero-log /dev/sdh1

 

Then restart the array.

YOU ARE THE MAN!  That worked.  Lesson learned, I will not be backing up my appdata folder.  

 

I owe you one, seriously!

On 7/5/2023 at 11:51 PM, JorgeB said:

It wouldn't because it may have the same end result but 's not the same problem, log tree is damaged, if that is the only issue this may help:

 

btrfs rescue zero-log /dev/sdj1

 

Then re-start array.

I know this is old, but just wanted to thank you because I was really stressing out & this saved me big time. God/Allah/Bob Dylan/all of them bless you.

Yes thank you!!! This worked for me too 😃 

 

btrfs rescue zero-log /dev/sdX1

 

Other searches just showed me to start 'copying' over files and reformatting the drive...

 

 

4 hours ago, johnnyfive said:

Other searches just showed me to start 'copying' over files and reformatting the drive...

Yeah, but please note that this will only work if the log tree is the problem, recommend always posting the diags in a new thread to confirm.

On 7/26/2024 at 3:46 AM, JorgeB said:

Yeah, but please note that this will only work if the log tree is the problem, recommend always posting the diags in a new thread to confirm.

Yeah it didn't solve the problem afterwards though.  Kept going back to unmountable after a restart.  I copied everything over and put in a new SSD as I'm unsure if my SSD is dead as it couldn't even be reformatted in unraid.  I took it to my other computer and reformatted it there though.. Seems to work.. but will use as a drive for not important things for now.

 

Thanks

Well, guessing i´m in this club also from today... I dont know what to do.
Been searching for a fix but i cant get it to work. This morning i rebooted the server and then one of my pools suddenly stop working.
The pool Cache_120gb is my docker pool. btrfs Unmountable: Unsupported or no file system



I tried to :
"Stop array and unassign both pool devices

Start array (click checkbox "I want to do this")

Stop array

Reassign both pool devices

Start array, post new diags."
But didnt work.

Later i tried the command:
btrfs rescue zero-log /dev/sdXX but i dont rly know what sdXX to choose.
Those drives in the cache pool is Raid1, btrfs and is encrypted, its named: sdh and sdk.

I tried:
btrfs rescue zero-log /dev/sdh

and
btrfs rescue zero-log /dev/sdk

but guessing i´m doing it wrong...

I´ll do daily backups for the system, havnt done a rollback yet.

oden-diagnostics-20240806-1940.zip