Unable to view directories in Files.app that are mounted with VeraCrypt

[pindab0ter]

Checklist

• Using latest version on the App Store
• Read the docs
• Searched for existing GitHub issues

Configuration

• App Version: Blink v17.3.0.916 (App Store)
• iOS Version: iOS 17.5.1
• Remote Machine: Debian 12 with VeraCrypt CLI 1.26.7

Describe the bug

When attempting to access directories associated with VeraCrypt mount points or directories within these mount points via the Files app, Blink returns a 'Content not available' error ("Inhoud niet beschikbaar", as translated from Dutch).

This issue shows up in three scenarios:

1. The directory is a VeraCrypt mount point.
2. The directory resides within a VeraCrypt-mounted volume.
3. The directory is a symlink pointing to a mount point or a directory within a mounted volume.

Steps to reproduce

1. Install VeraCrypt:
   • Install VeraCrypt Console on a Debian (or similar) machine.
2. Create and Mount a Volume:
   • Create a volume: veracrypt --text --create (e.g., test-volume.hc)
   • Create a directory for the volume: mkdir /media/test-volume
   • Mount the volume: veracrypt ./test-volume.hc /media/test-volume
3. Configure Blink and Files.app:
   • Add a Files.app entry in Blink for the connection with a parent directory of the folder containing the mount point (e.g., /, as it is the parent of /media).
   • Open the configured directory in Files.app—this should work.
   • Navigate to /media, where the mount point resides, and observe that the contents are not displayed.

Test directories within the mounted volume

4. Create a test directory:
   • mkdir /media/test-volume/test && touch /media/test-volume/test/test.txt
5. Create a new Files.app configuration:
   • Add a configuration to Blink that uses /media/test-volume/test as the root.
   • Attempt to access this new configuration from Files.app and observe the same issue.

Test symlinks to mount points and directories

6. Create symlinks:
   • ln -s /media/test-volume /tmp/test-volume-symlink
   • ln -s /media/test-volume/test /tmp/test-directory-symlink
7. Attempt to access symlinks:
   • Navigate to /tmp in Files.app—this directory loads.
   • Attempt to access test-volume-symlink or test-directory-symlink—they won’t load.

Other observations

• .blink/fileprovider.log shows no abnormalities during these operations. The log was cleared before connecting to a directory that won't load
  Click to view log output

      Aug 26 2024, 16:23:22 enumerator [info] NSFileProviderRootContainerItemIdentifier
      Aug 26 2024, 16:23:22 enumeratorFor  [debug] Initialized
      Aug 26 2024, 16:23:22 itemFor [info] NSFileProviderItemIdentifier(_rawValue: NSFileProviderRootContainerItemIdentifier)
      Aug 26 2024, 16:23:22 enumerator [info] NSFileProviderRootContainerItemIdentifier
      Aug 26 2024, 16:23:22 enumeratorFor  [debug] Initialized
      Aug 26 2024, 16:23:22 itemFor [info] NSFileProviderItemIdentifier(_rawValue: NSFileProviderRootContainerItemIdentifier)
      Aug 26 2024, 16:23:22 enumeratorFor  [info] Enumeration requested
    

• Other mounted volumes like those from my NAS work without issues.

[pindab0ter]

Maybe related to #1717?

[carloscabanero]

Thanks for the report! I don't think this one is related to 1717. I don't know about VeraCrypt so I'm going to need a little bit extra help from you here. Do you know if VeraCrypt needs to do anything with sftp or needs anything enabled on the sftp side for it to access it? Would you mind a quick test from your computer sftp to that location and see if that is going through without any additional configurations?

I have another idea of it could be as well, so already testing it from my side.

[pindab0ter]

VeraCrypt is software that enables you to mount encrypted volumes. It does not interact with SFTP itself for as far as I know.

When sftping into my machine it has no problem showing the contents of the mounted VeraCrypt volume.

[pindab0ter]

With the latest iOS update (iOS 18.0 (22A3354)) it now shows a loading spinner and "Loading" indefinitely instead of "Content unavailable".

[carloscabanero]

So I thought this had to do something with either requiring a specific sftp extension, or maybe even a problem with the way they se it up with the linked folders. It looks like we have discarded all those.

To continue moving forward, I need to have a VeraCrypt instance. Is there any script to set things up quickly in a remote machine? Or do you have a remote machine you could give me temporary access to? Or if I give you a remote machine, could you do a quick setup there so we can try things there?

Thanks!

[pindab0ter]

I could definitely set it up for you if you give me a remote machine.

I do have to say that the Files.app isn't working properly for me even without this issue since the last major point iOS update. To be more specific; I can see files but don't seem to be able to open them. So I'm still able to help troubleshooting this issue. Feel free to contact me using the email address on my profile page.

[carloscabanero]

Hi again @pindab0ter! I've been working on a new implementation for the Files.app due to the issues we have seen with the new iOS update. I would be nice to also get this Veracrypt stuff fixed so I appreciate the help.

So first things first, are you on TestFlight so you can access the new FileProvider and test there?

[pindab0ter]

I am, so that would work for me. Feel free to contact me by email using the address in my profile, or on Telegram or Discord using this same username.

[carloscabanero]

I’ve done some tests from the machine you set up, and the next version should fully support VeraCrypt-mounted volumes. I’ll push it so you can test before the weekend. The main issue was a bug in the attributes returned by the VeraCrypt mount, and we should now process those correctly.

There are two things to keep in mind due to the way VeraCrypt works:

1. It’s recommended to mount the specific location (the encrypted folder) rather than a different one. When Blink uploads files, it first creates a temporary file at the root of the mounted folder before moving it to the final destination. With VeraCrypt, moving files like this is not allowed—likely because the moved file isn’t "encrypted," so the operation is rejected. This also happens with SFTP. By setting the "root" as the VeraCrypt folder, the temporary files are already under VeraCrypt control, and all operations work without issues.

2. As you pointed out, it’s possible to mount and unmount the folder. Keep in mind that the FileProvider maintains a Replica of the destination. If you unmount the folder and then browse it, the Replica will "evict" all files from the local representation.

Keep an eye on that release and let me know if you find any other problems!

[pindab0ter]

With VeraCrypt, moving files like this is not allowed—likely because the moved file isn’t "encrypted," so the operation is rejected.

I’m just wondering, how is this different from copying/moving a file onto the mounted volume? Because that doesn’t seem to be an issue.

If you unmount the folder and then browse it, the Replica will "evict" all files from the local representation.

By which you mean the local cache will be deleted? That’s not a bug, that’s a feature! I’m only half joking, because we are of course talking about things stored in an encrypted volume. One should think about accessing that with this feature in the first place, but being able to clear the local representation like that makes it a little more palatable if anything. The two caveats you mentioned. It feels like they should be documented somewhere. I don’t have a clue where, but this isn’t intuitive, so it would be nice if there was somewhere publicly available that you could at least find this info if you were looking for it. I’m looking forward to seeing the TestFlight version updated.

[carloscabanero]

Cannot blame them on the attributes part, I was definitely making the wrong assumptions.

The reason why the mv works in your system but doesn't with SFTP is the way they are implemented. Your system knows the Veracrypt is another volume, so most probably is doing a cp and delete. But SFTP doesn't know about those boundaries and it implements this operation through a wstat (a rename), which in this scenario cannot work.

I will add all these notes in the documentation to the Files.app at https://docs.blink.sh/advanced/files-app

[pindab0ter]

Fair enough! Thank you for satisfying my curiosity and working on fixing this issue! I was reading through those documents and noticed that the following was not worded very clearly. I had to read it a few times to understand it.

iOS may not reclaim the disk space used by this extension, which could lead to the Blink App taking up alot of storage on your device. To free that space, delete (swipe left) and add again the Files.app directory in configuration for the Host. For more help, please leave a message in the Discussion.

I hope you don’t mind me suggesting an alternate phrasing: “To free that space, remove the Files.app directory from the Host configuration (swipe left to delete) and then re-add it.”

[pindab0ter]

I have tried the version currently on TestFlight. I am able to browse mounted volumes now, but not directories that contain a mounted volume.

[carloscabanero]

Hmmmm... I don't see that in the DigitalOcean machine, does it also happen for you there? Could you try moving the mounted volume to a different folder and see if that happens there too?

What may be happening is that a different file is blocking the enumeration for the directory. One thing I found before is that the properties of the mounted folder are different than those of other items. But I think I already accommodated for all those properties. I'm looking for something else I may be missing, like any other file or attributes that could be causing the enumeration for that folder to stop.

[pindab0ter]

My issue on the TestFlight version of the app does not seem to be related to the volume being mounted, as it currently seems that I am unable to display the contents of any Files.app configuration that is not initially set up as 'Replicated'.

If I add a new configuration (not replicated) it shows "No content available". If I then change it to "Replicated" and save it, it still shows "No content available". If I remove the configuration, save it, add it again as 'Replicated' it does work.

This is regardless of whether a VeraCrypt volume is mounted in that directory. It happens both on the DO test machine as well as my home server.

Please let me know if you want more information.

[carloscabanero]

Yep! I can replicate it and just fixed it 👍🏼

It is just that the FP cannot really transition from one to the other. We are going to release just the new one, so disable other paths and this won’t happen again.

But no changes on Veracrypt functioning, correct?

[pindab0ter]

‘FP’ being file provider and ‘the new one’ being the replicated behaviour?

But no changes on Veracrypt functioning, correct?

Correct!