Kopia cannot access the folder with the decrypted encfs files

General
1

Hello!

I have the following problem when trying to make backups using Kopia. All my personal photos are stored in an encrypted folder using encfs, for security reasons. I would like to back up this folder, but not the encrypted files, rather the decrypted ones. That is, after I decrypt and mount them with encfs. However, I do not know why Kopia cannot access the folder with the decrypted files.

One solution would be to keep all photos normally on the hard disk, which would allow me to back up without problems through Kopia, but this would mean a security issue - the source folder would be visible to anyone.

What solution do you propose to back up personal photos while keeping the source folder secure?

2

Well… afaiks, encFS is rather… ancient and having read read the Wikipwdia article about it, it rather seems that you would be better off to switch to something more modern. I am not quite sure, what the issue with Kopia would be here, but I think, that you will need a session with the encFS driver to be able to access the unencrypted files, while Kopia probably tries to access the files directly - without FUSE that is, and thus only grabs the encrypted ones. The article also notes some vulnerabilities, which would also suggest to move away from encFS…

If I were to choose one, I’d probably go with LUKS.

3

Ok, thanks for suggestion.

Ok, I agree that encfs is outdated. I tried your suggestion regarding LUKS. I created a LUKS partition, mounted it. I put some pictures in it. When I try to backup the decrypted LUKS folder, I get an error:

Error: internal server error: can’t get local fs entry: unable to determine entry type: lstat /test: no such file or directory

So, to make myself clear. I have encrypted family photos. I want to backup not the encrypted photo files, but the folder with the decrypted photos. And it seems that kopia doesn’t handle encrypted folders, whether it’s encFS, LUKS, or Cryptomator.

4

What and how exactly you are doing?

Where is your LUKS partition mounted?

Can you show the command you are using?

5

Configure LUKS partition:
cryptsetup -y -v luksFormat /dev/mmcblk0p2

Initializes the volume:
cryptsetup luksOpen /dev/mmcblk0p2 backup

Format Linux LUKS partition:
mkfs.ext4 /dev/mapper/backup

Mount the new filesystem:
mkdir /backup
mount /dev/mapper/backup /backup

Put some photo in /backup directory, and after that try to make a backup with kopia, which gives me the above error.

6

Given /backup mountpoint I guess you mount it as root?

Is kopia running as root too? What is filesystem you are using on your luks volume?

Because it all works without any glitch for me for ext4 formatted LUKS volume:

$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
...
/dev/mapper/my_encrypted_volume  974M  288K  908M   1% /home/kptsky/Temp/mount

$ kopia snapshot create /home/kptsky/Temp/mount/
Snapshotting kptsky@trixie01vm:/home/kptsky/Temp/mount ...
 * 0 hashing, 3 hashed (19 B), 0 cached (0 B), uploaded 206 B, estimating...
Created snapshot with root k4e010e7eb0f5617390ed517af35dc2f1 and ID 1998257e8658b6e2b95f29a0157d8234 in 0s

$ kopia snapshot list
kptsky@trixie01vm:/home/kptsky/Temp/mount
  2025-12-01 06:48:22 CET k4e010e7eb0f5617390ed517af35dc2f1 19 B drwxr-xr-x files:3 dirs:2 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)

so I strongly suspect that it is not kopia issue but something related to your setup.

7

Initially backup was mounted as root, but after that I change the owner to usual user:
sudo chown -R user:user /backup

Filesystem of LUKS partition is ext4.

Kopia is running in docker container:

docker-compose.yml

services:
kopia:
image: kopia/kopia:latest
container_name: kopia
restart: unless-stopped
privileged: true
cap_add:

  • SYS_ADMIN
    security_opt:
  • apparmor:unconfined
    devices:
  • /dev/fuse:/dev/fuse:rwm
    ports:
  • 51515:51515
    command:
  • server
  • start
  • –disable-csrf-token-checks
  • –insecure
  • –address=0.0.0.0:51515
  • –server-username=${USERNAME}
  • –server-password=${SECRET_PASSWORD}
    environment:
    KOPIA_PASSWORD: ${SECRET_PASSWORD}
    USER: ${USERNAME}
    volumes:
  • ./config:/app/config
  • ./cache:/app/cache
  • ./logs:/app/logs
  • /mnt/data/backup/kopia/repo:/repository
  • ./tmp:/tmp:shared
  • ./restore:/restore
  • /backup:/test:ro

Sorry, I don´t know how to post here (in markdown editor) formatted yaml.

8

Related LUKS partition, problem is solved. I think it was a docker issue, because after restarting the container, everything works fine.

But regarding directories encrypted with EncFS or Cryptomator, the problem remains unresolved.

1 Like
9

Any encryption you want to use with Kopia needs to somehow provide a POSIX-compliant volume, which presents the unencrypted files. I’d waste no time with any other solution.

10

Through all the above, I tried to understand how I could make a backup copy of my personal files, in the most secure way.

Now another question would appear, related to the backup mechanism of Kopia. Let’s say that I backup daily, and at some point bad sectors appear on the hard disk, and some files are damaged. Does Kopia have any mechanism to control the copied files, to check if they haven’t been damaged at the source in the meantime?

11

It is a good practice to run verification periodically. But above all the key is to have proper backup strategy - following the 3-2-1 rule is a good start. Every backup at some stage will get corrupted or destroyed - not if but when is the only question. This is my approach:)

1 Like
12

Okay, I understand. Kopia has a mechanism for verifying files in the backup. What happens if some files from the source become corrupted in the meantime? Does Kopia detect changes to the source (corrupted files) and overwrite them over the good files from the existing backup, or what happens in such cases?

13

No - and I don’t know of any backup software which does that. In the end the data on the source is the master, how can a backup software possibly decide when to automatically overwrite the data on the source with data from the backup? That’s never the call of the backup software to make and no vendor would ship such a system due to the implied consequences.

I am thinking, that you’re over-think the whole setup. And there is no such thing as a 100% certainty, that your data will be safe and secure, but you can minimize the risk, by taking @kapitainsky ‘s comment to heart.

2 Likes