I want to encrypt my data folder, in my case a drive, with luks so that theft of my hard drive won’t give easy access to all of my data.
Merely being an on and off linux user, by no means an expert and new to nextcloud, I’m looking for advice on how to accomplish this.
Do I need to stop nextcloud from starting up on system startup and how do I do this. (So the encrypted drive can be mounted first)
What are your thoughts on any monitoring during normal use.
So, the encrypted drive is mounted, nextcloud is running - does it make sense to monitor if the drive is still mounted and if it isn’t, stop nextcloud somehow?
Just wondering about this, after reading that if nextcloud loses its data folder there have been cases of nc deleting all the data on the clients (syncing ‘nothing’ with the clients).
Not sure if this would be too much of a brute force solution that causes more problems than it solves. Or would you just trust that once the drive is mounted it will stay that way, let nc handle any faults and hope for the best?
Is there any sort of shutdown routine I need to let know that nc needs to be terminated first, then the drive needs to be unmounted/locked and then the shutdown can be initiated?
(I’m using a raspi 5 with ubuntu server, nc snap package and a usb3 hard drive for the data)
So I don’t use that. Of course, it only makes sense if you are afraid that someone (at your home) will steal the hard drive. You have to judge whether this is likely.
If so, then you should enter the password manually when starting the Pi or decrypting the LUKS partition after boot. Because if you don’t do this, the Pi and hard drive can still be stolen.
Either the system will only boot after the password has been entered. Alternatively, you can simply not allow the web server to start automatically and only start it after decrypting the partition. Also do not use Nextcloud cron before mount.
I can’t say much about the clients. This may be a separate problem.
Note that the hard drive is decrypted during operation. LUKS does not protect against attacks during operation. For that you need End-to-End-encryption (not transport encryption / not sever side encryption). With E2E you must use the clients. Web GUI does not work.
Alternatively, you can also encrypt on the client side, e.g. with encrypted ZIP files, Boxcryptor, etc. But you won’t be able to use the data via different clients such as desktop and smartphone.
Usually, you just enter the passphrase at boot time before any services start. The underlying storage being encrypted is transparent/invisible and the order of operations (i.e. of mounting/unmounting) is handled outside the scope of Nextcloud.
I tried this out but the disable command also stops nextcloud. This means it has to be run just before every shutdown.
Is there a way to deactivate Nextcloud from starting up when booting without having to run a command before shutdown?
Or as I only use snap for nextcloud, should I look into stopping snap from starting automatically when booting?
The most elegant way would be to decrypt the drive during the boot process and configure the systemd service for snapd so that it only starts when the partition is decrypted and mounted.
Note: I used ChatGPT to write the following, and as far as I can tell it should work. However, I strongly recommend that you do some research on your own to make sure you understand exactly what each part does before blindly applying this to your production system.
1. Add the LUKS Drive to /etc/crypttab
This ensures the system decrypts the drive at boot.
Identify your LUKS device:
lsblk -o NAME,UUID,MOUNTPOINT,FSTYPE
Find the encrypted partition (e.g., /dev/sdX or /dev/nvme0n1pX).
Edit /etc/crypttab:
sudo nano /etc/crypttab
Add an entry in the format:
luksdrive UUID=<your-UUID> none luks
Replace <your-UUID> with the actual UUID of your LUKS partition.
2. Ensure Systemd Mounts the Decrypted Drive Before snapd Starts
Once decrypted, you want the system to mount it before starting snapd:
Edit /etc/fstab:
sudo nano /etc/fstab
Add an entry for the decrypted device (adjust the mount point as needed):
Sorry but I completely disagree. LUKS is a well documented and proven technology on Linux that I trust a hundred times more than Nextcloud Encryption. Just search for issues with Nextcloud encryption here in the forum and on GitHub, sorry, but you really don’t want to have to deal with that
LUKS, on the other hand, is completely transparent to the software running on your system, and if something goes wrong with Nextcloud, you can still mount a LUKS encrypted disk on any Linux system and access the data. And if you run into any issues, there are plenty of howtos and help on the Internet.
Btw, I did some more research and instead of mounting the drive with fstab and then telling snapd to start after systemd-cryptsetup as shown in chapter 2 of my previous post, you could create a systemd mount unit that starts after systemd-cryptsetup and before snapd to ensure that the drive is not only decrypted but also mounted when snapd starts.
sudo nano /etc/systemd/system/mnt-mydata.mount
Add the following: (Make sure you modify it according to your setup)
