I recently migrated a local encfs filesystem to rclone crypt to make it easier to mount remotely.
The setup is: /path/enc mounts to /path/A/unenc on Machine A via the local file system via crypt. Machine B then mounts Machine B:/path/enc to /path/B/unenc.
Neither uses any special flags, e.g., Machine A executes rclone mount enc: /path/A/unenc --daemon.
Both Machine A and B can create and delete files and directories without a problem. However, if I execute touch on either file it gives the error touch: failed to close '/path/to/file': operation not permitted and the time stamps are not updated.
The files display the correct modification times, i.e., corresponding to when the files were created, but I need to be able to update those in order for certain cron jobs to pick them up. If there is some other way of doing that besides using touch, that's fine, but I have to be able to execute it after the files are written to the crypt mount.
FYI: the times are correct on the underlying encrypted files. If I run touch on them, the times update (i.e., in ls -l), but the corresponding decrypted file in the mount still shows the old creation time.
First thing to try would be to use rclone touch.
As you can imagine it works very similarly to the Linux touch command, but since it is designed to interact with rclone remotes it may not face the same problem, whatever the cause might be.
I am not entirely sure if this will change the dates on the contents of a encrypted file as well, but I would not be surprised if it did. I just don't know quite enough about how the data is packed to know if this is viable to expect from it.
The second issue to think about is permissions.
The vast majority of cloud backends only save basic metadata and have no concept of permissions, so any such settings on the files are lost. The effective permission settings on a mounted file is whatever you set the mount's permission mask to be.
If you are familiar with Linux permissions this probably makes sense to you:
I don't immediately see why the default permissions should cause a problem in updating a timestamp, but if the first suggestion doesn't fix the problem then the first thing I'd do is check is to open up the permissions temporarily to eliminate this possibility.
That did the trick! I thought I would have to run it through the crypt mount, but I can actually just run it right against the decrypted file in the local mount, which is great because I can just add 'rclone' in front of touch in my scripts.
the crypt remote should be "content aware" to speak. The unencrypted files you see are just virtual after all, and in reality you are working directly on the encrypted files. The crypt layer just translates it.
