macOS rclone mount - new FUSE-T released - old issues fixed

New FUSE-T has been released:

fixes ModTime update on read problem:

File access and modification times cannot be set separately as it seems to be an issue with the NFS client which always modifies both. Can be reproduced with 'touch -m' and 'touch -a' commands

Workaround with latest FUSE-T is to use -o noatime and/or -o nomtime

There is also new -o nfc (added in v1.0.21) option which improves UTF8 encoding issues when working in multiplatform environment by enforcing all content saved to mount to normalise to NFC (used on Linux and Windows).

New options can be used in rclone mount command:

rclone mount remote: mountpoint -o nfc -o noatime

There are still issues with UTF8 encoding when content is saved on macOS to remote via rclone copy/move/sync (as it is NFD normalised) but this should be alleviated by VFS normalisation which is aimed for rclone v1.64:

1 Like

do you suggest to wait for the 1.64 rclone release which should hopefully include VFS auto normalization?

Until this is implemented (hopefully in 1.64 but who knows) there is really no good solution.

My workaround at the moment is to use fuse-t:

rclone mount remote: mountpoint -o nfc -o noatime -o modules=iconv,from_code=UTF-8,to_code=UTF-8

this solves problem of new files uploaded to remote via mount (NFD or NFC they are normalised to NFC).

And if I have local files I want to sync to remote I make sure that they are all NFC normalised before.

$ brew install convmv
$ convmv -r -f utf8 -t utf8 --nfc --notest .

To make rclone macOS mount to work both in Finder and shell, only way now is to make sure that your mount does not have any files using NFD normalization and use -o nfc -o modules=iconv,from_code=UTF-8,to_code=UTF-8 with fuse-t. macFUSE is totally broken.

Thanks you for the info! I have resisted FUSE-T on my home mac but as soon as I hit reply, I am uninstalling the KEXT and installing FUSE-T

1 Like

If you have any observations re fuse-t - good/bad does not matter - please share.

I actually just switched back to the KEXT. I know the days are numbered but, at least for now, it was a (mediocre) solution to my problem.

I haven't had time to fully jump in and debug or gather a working minimal example but I keep running into problems that I think are more related to an idiosyncrasy in VLC than in FUSE/FUSE-T and/or rclone.

When you open a video in VLC, it opens in a mode that allows for some modification (sorry, I don't recall the flag). These are on crypt-wrapped local "remotes" stored on an external drive.

  • macFUSE:
    • --vfs-cache-mode off: Reads the file perfectly fine. When you go to unmount, you get lots of errors in the logs but the files are untouched and they don't have an effect other than to slow down the unmount. (acceptable)
    • --vfs-cache-mode writes: Writes the files back which is very slow and updates the ModTime (unacceptable and slow)
  • FUSE-T:
    • --vfs-cache-mode off: VLC just can't read the file. It gets itself in a loop. (NOT usuable)
    • --vfs-cache-mode writes: Reads the file and doesn't write the whole thing back from the cache but does update ModTime (not ideal but fast)

So, for now, I am sticking with macFUSE and no cache. I am fairly certain that the updated ModTime is correct as far as rclone behavior goes because VLC is opening to write so it isn't related to the fixed issue in FUSE-T nor is there a bug in rclone.

And I am know my days are numbered. If the KEXT becomes too unstable or Apple blocks them for good, I will have to make due (probably decide to stop caring about ModTimes but that will make me sad. And I don't like --size-only for later backups). But given that it is working, I am going to stay in my ways.

And of course, relevant XKCD


@jwink3101 I'm curious what happens if you try the same VLC experiment with a normal local file (not mounted via rclone). Does the ModTime still get updated?

I'm interested because I also care about ModTimes and have seen some similar unexplained issues with them when mounting on macOS (and specifically upon unmounting, like you described). More recently I've been wondering if there might be an issue in the VFS layer itself, as I've also seen some odd behavior with rclone serve sftp, which shouldn't be using FUSE at all (but I'm not yet sure whether or not the issues are related).