Broken link to external USB data directory

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face: is for home/non-enterprise users. If you’re running a business, paid support can be accessed via where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:


Or for longer, use three backticks above and below the code snippet:


Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 18.0.2):
Operating system and version (eg, Ubuntu 20.04): Nextcloudpi v 1.31.0
Apache or nginx version (eg, Apache 2.4.25): Unsure how to find this
PHP version (eg, 7.1): Unsure how to find this

The issue you are facing:
My Pi had it’s data on a USB, automounted and everything worked ok. I was very pleased as I am beginner and stretching my skills all the time.

Something happened, an update from ncp 1.28 was stuck and the datadir didn’t have the .ocdata file, so I have been out of sync for about 5 days. I managed to log into SSH and update the nextcloudpi version but can’t fix the usbdrive issue.

The usb datadir was mounted under /media/myCloudDrive/ncdata. That is no broken/gone as my ncdatabase if now pointing to /media/USBdrive/ncdatabase with seemingly no entry for ncdata. Can I reconnect these links?

I have tried repairing the link from the command line of SSH but I keep getting ‘permission denied’ if I try to add field or folders. I tried to check the folder size to see if my data is still intact but also denied.

If I try to go to the log in screen I get the message

Your data directory is invalid Ensure there is a file called ".ocdata" in the root of the data directory. Cannot create "data" directory This can usually be fixed by giving the webserver write access to the root directory. See

I have read this but can’t make sense of it (sorry).

Is this a simple fix or have I really borked it this time? Any help will be greatly appreciated.

NAME        FSTYPE LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINT
└─sda1      btrfs  myCloudDrive [removed in case it is sensitive)               

My original drive still seems to be intact. Can I use the UUID to remount the drive? I will look into this while I await any assistance.

Join and share your post there as well. Sorry to hear about the confusion.