Nextcloudpi: ncp-backup always fails with I/O error

I am a newbie to Linux as well as to Nextcloud. As a start I bought a Nextcloudpi and did a successful installation of Nextcloud on an 127 GB SD card. Everything is running fine, but now I would like to backup my Nextcloud data to an external device.

For this reason I have connected an 256 GB SSD via USB to the Raspberry Pi. Then I was following How to configure an external USB drive with NextCloudPi to enable automount, and to format the SSD as btrfs.This was done using the Web-access via nextcloudpi:4443.

I did not configure Nextcloud data, Nextcloud database, or the swap file to be on the SSD, since I wanted to have a media for backup purposes only.

Unfortunately, I cannot get the ncp-backup to run. Everytime, I try to run it - via web-access or via SSH - I get the following status:

[ nc-backup ]
check free space…
Maintenance mode enabled
backup database…
backup base files…
tar: /media/NcpBackup/ncp-backups/nextcloud-bkp_20181010_1539191061.tar: Cannot write: Input/output error
tar: Error is not recoverable: exiting now
error generating backup
Maintenance mode disabled

At the same time I get the following error messages at the console output:

[ 615.681115] BTRFS: error (device sda1) in btrfs_commit_transaction:2253: errno=-5 IO failure (Error while writing out transaction)
[ 615.689728] BTRFS: error (device sda1) in cleanup_transaction:1873: errno=-5 IO failure

In most cases afterwards the device sda1 is gone, and a new sdb1 device exists pointing to the SSD but in read only mode. I then disable automount and enable it again via Web-access. Then I have my SSD again available as sda1 with read-write access.

I can access the SSD via the console or via SSH just fine, and write to it. But the backup via the ncp panel fails everytime.

Any help is highly appreciated.

Best regards


  • NextCloudPi version: v0.62.6
  • automount: yes
  • USB devices: sda
  • datadir: /var/www/nextcloud/data
  • data in SD: yes
  • Nextcloud version:

looks like you are having hardware problems with the hard drive… I would run a smartctl scan

Dear nachoparker,
thanks for your reply - and sorry for me coming back so late (work :slightly_frowning_face:).

In the meantime I did some testing:
I can confirm, that it is not a hardware problem with the SSD. I tested the SSD several times with different tools in my Windows PC, and everthing is fine; perfectly read- and writable, no SMART alarm.

The unreliable connection of the USB drive is manifested in a failed startup or reboot of the Pi as well, in which it always checks the disk, and falls back in maintenance mode.

My first step was to connect the SSD to an Icy Box IB-111StU3 USB 3.0 single bay docking station, which has its own power supply. And voilá: The Pi came up after shutdown without a problem, several reboots without a hitch. But this docking station is for temporary preparation of hard disks, and not for permanent connection to the Pi. (It is too big also, since it can hold a 3.5 " drive as well.)

Since the other SSD enclosure did not have its own power supply I suspected that the SSD would draw too much power from the Pi, even though I bought a recommended power supply with 3A output power. Therefore, I bought an extra self-powered 4 port USB 3.0 hub from Anker with its own power supply via an USB cable. I connected the Icy Box SSD enclosure to the Anker hub (with its own power supply plugged in), and connected it again to the PI: but no luck - three out of four reboots of the PI failed again! So it was not the power supply, which gave problems.

In a second round testing, the docking station connected did fail also during reboot, and the SSD enclosure sometimes came up without failure. Nevertheless, the docking station was considerable more reliable than the SSD enclosure.

  • Anybody has an idea what to do to get a higher reliability during reboots of the Pi?

In addition I checked the USB controllers, which were used in the two devices, the Icy Box docking station, and the Icy Box SSD enclosure, with lsusb:

  1. Docking station (working)

Bus 001 Device 005: ID 174c:5136 ASMedia Technology Inc. ASM1053 SATA 6Gb/s bridge

  1. SSD enclosure (not working)

Bus 001 Device 008: ID 152d:9561 JMicron Technology Corp. / JMicron USA Technology Corp.

I tried to find out, which controller is behind the ID 152d:9561. I suspect, it is a JMS578. The ASM1053 is already on the market quite some time, the JMS578 is younger. This I find now a little bit worrysome:

  • Is the Pi (or Debian for that matter) so picky about the USB controllers used in the different hardware devices?
  • How does someone choose an SSD enclosure for the PI, if it is not known which USB controller will be used in there?

This topic was addressed in Using your Pi with an SSD (Solid State Drive) also.

Like everybody, I prefer a reliable system since I trust it with my valuable personal data. If I get a higher reliability by spending a few bucks more, I would happily do it.

Any help is highly appreciated.

Most issues are related to the power supply. It is always highly recommended to have separate power supply for the drives.

Hopefully somebody will share their experiences

And it turns out - Nachoparker is right: It was related to the power supply!

What did I do:

  • Bought an original Raspberry power supply
  • Put the SSD back in the Icy Box SSD enclosure (IB-253U3) w/o own power supply
  • Connected it to the Anker Ultra Slim 4 Port USB 3.0 Hub (AK-A7518311) with Micro USB cable and 10W power supply
  • Plugged the Raspberry and the Anker hub power supplies into a manifold-plug with on/off-switch
  • Switch the manifold-plug on
  • Ran several restarts and total shutdowns for testing purposes: Not a single failure! Neither after restarts nor shutdowns!

The bottom line for me from this experience after hours of searching and scratching my head:

Make sure that you have a good and reliable power supply for your Raspberry Pi. Otherwise all kinds of weird errors might occur. And do have a separate power supply for your additional drive.

good for you! this is extremely common, and that is why it is repeated in the wiki, FAQ and forums nonstop