# Kopia cannot access the folder with the decrypted encfs files

**URL:** <https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717>\
**Category:** General\
**Created:** [November 23, 2025, 10:15am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717 "2025-11-23T10:15:14Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Antisthius](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/antisthius/32/1914_2.png) [@Antisthius](https://kopia.discourse.group/u/Antisthius)\
**Post date:** [November 23, 2025, 10:15am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/1 "2025-11-23T10:15:14Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![budy](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/budy/32/38_2.png) [@budy](https://kopia.discourse.group/u/budy)\
**Post date:** [November 24, 2025, 7:51am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/2 "2025-11-24T07:51:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Antisthius](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/antisthius/32/1914_2.png) [@Antisthius](https://kopia.discourse.group/u/Antisthius)\
**Post date:** [November 30, 2025, 6:20pm UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/3 "2025-11-30T18:20:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kapitainsky](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/kapitainsky/32/535_2.png) [@kapitainsky](https://kopia.discourse.group/u/kapitainsky)\
**Post date:** [November 30, 2025, 7:08pm UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/4 "2025-11-30T19:08:50Z")

</div>

What and how exactly you are doing?

Where is your LUKS partition mounted?

Can you show the command you are using?

---

<div class="post-metadata">

**Author:** ![Antisthius](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/antisthius/32/1914_2.png) [@Antisthius](https://kopia.discourse.group/u/Antisthius)\
**Post date:** [November 30, 2025, 7:47pm UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/5 "2025-11-30T19:47:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kapitainsky](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/kapitainsky/32/535_2.png) [@kapitainsky](https://kopia.discourse.group/u/kapitainsky)\
**Post date:** [December 1, 2025, 4:41am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/6 "2025-12-01T04:41:32Z")

</div>

> [@Antisthius](#):
>
> mount /dev/mapper/backup /backup

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:

```auto
$ 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.

---

<div class="post-metadata">

**Author:** ![Antisthius](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/antisthius/32/1914_2.png) [@Antisthius](https://kopia.discourse.group/u/Antisthius)\
**Post date:** [December 1, 2025, 8:33am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/7 "2025-12-01T08:33:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Antisthius](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/antisthius/32/1914_2.png) [@Antisthius](https://kopia.discourse.group/u/Antisthius)\
**Post date:** [December 1, 2025, 10:55am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/8 "2025-12-01T10:55:17Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![budy](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/budy/32/38_2.png) [@budy](https://kopia.discourse.group/u/budy)\
**Post date:** [December 1, 2025, 11:57am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/9 "2025-12-01T11:57:17Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Antisthius](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/antisthius/32/1914_2.png) [@Antisthius](https://kopia.discourse.group/u/Antisthius)\
**Post date:** [December 3, 2025, 5:22pm UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/10 "2025-12-03T17:22:08Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![kapitainsky](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/kapitainsky/32/535_2.png) [@kapitainsky](https://kopia.discourse.group/u/kapitainsky)\
**Post date:** [December 3, 2025, 6:36pm UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/11 "2025-12-03T18:36:24Z")

</div>

> [@Antisthius](#):
>
> Does Kopia have any mechanism to control the copied files, to check if they haven’t been damaged at the source in the meantime?

> **[Verifying Validity of Snapshots/Repositories and Trying to Repair Any Corruption](https://kopia.io/docs/advanced/consistency/)**
>
> Fast and Secure Open-Source Backup Software for Windows, Mac, and Linux

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:)

---

<div class="post-metadata">

**Author:** ![Antisthius](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/antisthius/32/1914_2.png) [@Antisthius](https://kopia.discourse.group/u/Antisthius)\
**Post date:** [December 4, 2025, 8:58am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/12 "2025-12-04T08:58:36Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![budy](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/budy/32/38_2.png) [@budy](https://kopia.discourse.group/u/budy)\
**Post date:** [December 4, 2025, 9:50am UTC](https://kopia.discourse.group/t/kopia-cannot-access-the-folder-with-the-decrypted-encfs-files/8717/13 "2025-12-04T09:50:12Z")

</div>

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.
