Encrypted instance - Password error

ℹ️ Support
, , ,
1

Nextcloud version (eg, 29.0.5): 28.0.10(?) NextcloudPi v1.55.2
Operating system and version (eg, Ubuntu 24.04): nextcloudpi
Apache or nginx version (eg, Apache 2.4.25): nextcloudpi
PHP version (eg, 8.3): nextcloudpi

The issue you are facing:
I’ve encrypted my local nextcloudpi installation, and normally I just past the password after an outage; the disk is then decrypted and I can access nextcloud. However, this time, after a short power outage, I get a “Password error”.
I am pretty sure the password is correct, as it has been in the password manager, which does not indicate any changes in its history.
Is there any way how I can manually decrypt or debug this?

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. Pull the power plug of the raspberry pi; reconnect power a few seconds later.
  2. Access https://. A page “NextCloudPi Encrypted instance” pops up.
  3. paste the password into the password field. Click “Decrypt” button.
  4. Error message appears under the “Decrypt” button: “Password error”.

The output of your Nextcloud log in Admin > Logging:
can’t get this at this stage :slight_smile:

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):
Can’t get this at this stage

The output of your Apache/nginx/system log in /var/log/____:
Can’t get this at this stage

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.
Can’t get this at this stage

In /var/log/ncp.log, I get:

[ nc-encrypt ] (Mon Oct 28 07:28:05 GMT 2024)
ESC[0;1;31mFailed to start transient service unit: Invalid environment block.ESC[0m
2

Seems more like a corrupted drive.

3

Thank you @Kerasit .

Sorry, took me a while to figure things out.

I wonder where the corruption is, and why it does not decrypt the harddisk - and then, I obviously wonder how I best restore everything to a workable state.

Setup:

  • Nextcloudpi on memory card inside the raspberry pi; headless
  • data encrypted on USB attached SSD (1TB)
  • new USB SSD (1TB) available

This is a screenshot of the issue:

image
image955×630 82.4 KB

The system seems to be unable to decrypt the ssd.

This still works:

  • I can still access the raspberry pi via ssh. The database and some other stuff seems to be on it and accessible.
  • I am able to access the content of the data SSD by mounting it with gocryptfs ./ /mnt/mydata (and typing the password).

It confuses me that, if both these things work, the password screen from raspberry refuses the password. And it confuses me that I need a password, even if the ssd is not attached to the pi.

However, I want to move on.

How can I connect the new ssd to my existing nextcloudpi?
I assume if I simply copy the data from the old to the new ssd, I’ll have the same problem as right now?!
I would even set up everything from scratch and restore data from backup, but actually, I prefer to do it in a way where I have got all data encrypted AND know what to do in the event of an SSD failure.

I will double check and try to re-connect the old SSD. As I experience the same behavior no matter if the SSD is connected or not, I can imagine either the USB connection was not okay, or the issue is somewhere on the memory card of the Raspberry.

4

The disc itself is not damaged. The thing is that single sectors always corrupts over time. A simple re-write of the sector fixes it. However this is excactly why you are mirroring discs - or at least one of the absolutely most important reasons: re-silvering and scrubbing.
It seems you are just that unlucky guy where a corrupt sector happens to be at a worst possible - ever - spot.

If you cannot decrypt it, there is litteraly nothing you can do about it. Or that is not entirely true. There is a toolbox that you can find by following the documentation or searching here on forum, for how to decrypt single files. You could use that to decrypt all the files and then install again…?

5

Thanks for the reply, @Kerasit!

Ah, that’s right: Mirroring would in hindsight probably have made things much easier. I didn’t mirror, because I’ve got a backup of my data in the cloud; that’s fine for me. Oh, and because I was unsure about mirroring with external USB drives.

I have continued the investigation a bit. As I actually could decrypt the ssd content via command line on another linux machine, I wondered why just not directly on the raspberry pi.

In fact, while on the other machine I could see the encrypted directory listings after mounting the ssd, this is what I got on the raspberry pi:

pi@nextcloudpi:/media/storage1tb $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        30G  8.1G   20G  29% /
devtmpfs        1.7G     0  1.7G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           759M  1.2M  758M   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
/dev/mmcblk0p1  255M   31M  225M  12% /boot
/dev/sda1       932G  535G  397G  58% /media/storage1tb1
tmpfs           380M     0  380M   0% /run/user/1000

pi@nextcloudpi:/media/storage1tb $ du -sh
20K	.

pi@nextcloudpi:/media/storage1tb $ mount
[...]
/dev/sda1 on /media/storage1tb1 type btrfs (rw,nosuid,nodev,relatime,ssd,space_cache,subvolid=5,subvol=/,uhelper=udisks2)
[...]

This means, the same file system seems to be nearly empty on one machine via du -sh (but not via df -h), and totally okay on the other machine.

I therefore mounted and decrypted manually:

# mount /dev/sda1 /media/USBdrive

and then tried to decrypt manually:

# gocryptfs ./ /media/storage1tb/
Invalid mountpoint: directory /media/storage1tb not empty

This issue is explained (but not 100% resolved) here: mount point must be empty? · Issue #357 · rfjakob/gocryptfs · GitHub

Therefore:

# gocryptfs -nonempty ./ /media/storage1tb/
Btrfs detected, forcing -noprealloc. See https://github.com/rfjakob/gocryptfs/issues/395 for why.
Password: 
Decrypting master key
Filesystem mounted and ready.

While this worked, from that point on, I
a) got the nextcloudpi “Activation Screen” attempting to set new passwords when trying to access nextcloud via the browser
b) the raspberry shell would hang and kick me out a lot, not even let me list /media/storage1tb.

Well, if a full re-install and full data restore is the way to go, then that’s fine. I just do not have the feeling i would either understand or got it all under control yet :frowning:

6

I have now re-read your post. It seems that the block damage is on your SD card that hosts the loader. It seems that there is nothing actually wrong with your external HDD.

Raspberry PI’s has been known to kill SD cards. And yes, it probably is only a specific block on the SD card that is broken.

Here is what I would do if I was to build on a PI:

  • Format the new SSD so you have 15-20% if the capacity as one EXT4 partition. The rest must be a none allocated space.
  • Boot from the USB drive instead of the SD card. You can change this in the BIOS.
  • Then install OpenZFS.
  • Install incus (or LXD).
  • Initiate your first incus/lxd. For storage, choose ZFS. Use all the none allocated space.
  • Install nextcloudpi - or any other AIO of your own choice - in a fresh container.
  • When you got Nextcloud up and running, attach your “old” disc.
  • Decrypt it, mount it and start uploading all the data into the root users folder - with folder structure and everything - using rsync.
  • When all data has been moved over - still not started any installation - I would then format the old SSD. Now create one ZFS partition excactly the size of the other one you have on the new SSD or bigger. It does not really matter, as long as it not smaller.
  • Now add this to the current ZFS pool for your Incus environment, and you have mirrored your data discs.

If using Debian or centos, you can use OpenZFS for the entire disc, hence you can mirror it all and can follow the NexcloudPI installation isntructions, except you cannot use any of the BTRFS instructions and snapshotting. This you will have to setup using zpool commands yourself, so there is a learning curve.

I would still recommend the LXC road though. But that is just a personal preference.

7

Wow, thank you @Kerasit , that’s very comprehensive.

I did not know OpenZFS, incus and LXD yet. Sounds amazing! I guess this is not as simple as “headless” plugging an SD card in, but from what I understand, it’ll have the benefit of having the data disks mirrored AND with the additional integrity checks, self-healing functions and encryption seem to far outweigh the benefits of a less complex installation.

I will have a thorough look at this over the next days. Still need to look into OpenZFS, LXC, and incus. For Nextcloud, I might go either for Ubuntu with a snap nextcloud on top of it, or for nextcloudpi.

Thanks again; those three new-to-me tools seem to solve all the problems I can imagine :smiley:

1 Like
8

Yes, it does indeed.

OpenZFS has native encryption features. Se here: OpenZFS Native Encryption - Klara Systems

be aware though that it has to be defined at the time of creating the datasets. However you can do this when creating the pool, where you can apply this to all datasets in the pool.

I wonder, though, why you need encryption in the data-at-rest if the PI is in your own home?