Nextcloud version : 22.214.171.124
Ncp version: 1.48.3
Operating system and version : debian 11 bullseye
PHP version : 7.4.30
The issue you are facing:
The server stops working after a few days with “your data directory is not writeable”. I’m using a 4tb usb hard drive for ncp and a 2tb hdd where I save the backups. The drive is new and the system worked flawlessly for about a month. I started the server from a fresh install when using the new drive, I formatted it with ncp-config tools.
The first times this error appeared a reboot would fix it, but after 2 or three times it wouldn’t be enough and I had to use btrfs repair commands.
This now is the output of btrfs —check : Btrfs —check output - Pastebin.com
Is this the first time you’ve seen this error? (Y/N): no
Steps to replicate it:
- Keep the server up and running
Output of ncp-report: Ncp-report - Pastebin.com
Any idea on how to fix it? I don’t think the drive is bad, it only has two months and doesn’t make any weird noise
If any other info is needed tell me!
The discs are powered by the RPI USB or they have an independent power supply?
I’m using a rock pi x https://wiki.radxa.com/RockpiX
The data hdd is connected to the usb3 through a powered usb hub (only the disk is connected though)
The backup hdd is directly connected to the usb
It is better to connect the two disks to the usb hub to make sure there are no power issues.
I don’t know rock pi x but on rpi 4 these problems happen.
And make sure that the USB hub can provide enough power to both disks.
i looked at config.php and tempdirectory is pointing to the correct directory, looking inside the tmp folder i see many things so i think it is being used
I don’t know for sure your drive is bad I’m only looking at the info you’ve provided of your logs and what you’ve written, which points to having such an issue.
It doesn’t have to make any weird noises to have a corrupt filesystem, filesystem metadata or broken inodes.
A lost write can cause it, for instance, if the drive is plugged into a device that can’t properly provide the power the drive requires to operate or the power delivery dips to low enough levels during a write and causes a failed or bad write to the drive.
Do you have any errors about power in
Error: parent transid verify error
Reason: result of a failed internal consistency check of the filesystem’s metadata.
[ 4007.489730] BTRFS error (device vdb): parent transid verify failed on 30736384 wanted 10 found 8
The b-tree nodes are linked together, a block pointer in the parent node contains target block offset and generation that last changed this block. The block it points to then upon read verifies that the block address and the generation matches. This check is done on all tree levels.
The number in failed on 30736384 is the logical block number, wanted 10 is the expected generation number in the parent node, found 8 is the one found in the target block. The number difference between the generation can give a hint when the problem could have happened, in terms of transaction commits.
Once the mismatched generations are stored on the device, it’s permanent and cannot be easily recovered, because of information loss. The recovery tool
btrfs restore is able to ignore the errors and attempt to restore the data but due to the inconsistency in the metadata the data need to be verified by the user.
The root cause of the error cannot be easily determined, possible reasons are:
- logical bug: filesystem structures haven’t been properly updated and stored
- misdirected write: the underlying storage does not store the data to the exact address as expected and overwrites some other block
- storage device (hardware or emulated) does not properly flush and persist data between transactions so they get mixed up
- lost write without proper error handling: writing the block worked as viewed on the filesystem layer, but there was a problem on the lower layers not propagated upwards
it did btrfs defrag and it’s now running btrfs balance. I’ll post asap dmesg results
Thanks for helping!
maybe it would be better to return the drive to amazon (if possible) and use a desktop hdd with a proper dock with external power supply
but first i anyway need to make a backup
Yes, if you’re using a RPi4 then I would definitively recommend an external drive which has its own power delivery (it’s what I’m using with mine), even using a bad power supply for the pi itself can cause issues.
Which I also encountered in the beginning of using my raspberry pi that came with a USB power supply plus cable and I had to buy a proper one from raspberry pi store
btrfs balance failed due to input/output error (≧﹏ ≦)
Yeah … sorry to be the bearer of bad news, but it does appear more indications of corruption. Of course I could be wrong , there is also no sign of power issues, at least as far as I can tell.
This is from your
dmesg log however and that you had an I/O failure is another indication of corruption…
[ 566.662886] BTRFS error (device sdb1): block=42418176 read time tree block corruption detected
. . .
[27239.569529] BTRFS error (device sdb1): parent transid verify failed on 290209792 wanted 9311 found 9203
[27239.587459] BTRFS error (device sdb1): parent transid verify failed on 290209792 wanted 9311 found 9203
[27244.129632] BTRFS info (device sdb1): balance: ended with status: -5
i was able to use btrfs check --repair -p /dev/sdb1 and then delete the two temporary folders that were corrupted.
nextcloud still works and i’m doing a complete backup, i hope it will end without errors.
Then, new drive and power supply for the board.
I’ll write here if the problem comes back
I’m glad you were able to locate & remove the corrupted folders and repair it to make a backup.
Yes, hopefully it’ll go alright
You’re welcome & good luck