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

Howto Guides
1

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
2

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

3

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.

4

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
5

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

6

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

2 Likes
7

@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).

8

For anybody interested. The latest FUSE-T also supports smb style mount

It seems that macos SMB client is more stable than NFS and doesn't have the following bugs: #45, #17
Keep in mind this feature is highly experimental and might not be ready for production yet.

9

Hmm. More stable? Probably; SMB is quite stable overall, and has been so for several years.

But the issue is "speed". SMB is "ok" I guess; but NFS is blindingly fast (for many reasons, a few of which include the little regard they have towards complex authentication features, although v4 is supposed to play well with Kerberos and such).

10

As a frontend to serve remote cloud storage I think speed is not really critical - your bottleneck is somewhere else anyway. Similarly all security and authentication or their lack is not so important when only used for local machine.

We are talking here about local server not client. If you try serving nfs and/or smb from macOS you will discover soon that none is rock solid stable. Clearly their dev in macOS environment is not priority.

1 Like
11

I stand corrected! Aye, you're absolutely correct in that; in fact, I have never managed to share anything on my Mac to any of the other computers in the network ā€” no matter what I tried (granted, I didn't try very hard).

My apologies for the confusion. Indeed, I was thinking about the client-side, not the server-side of sharing...

12

Did it work for you? When I passed those args through rclone, it didnā€™t work

13

Yes it works:

rclone mount crypt: ~/Temp/mount --vfs-cache-mode=full -vv -o backend=smb

and indeed creates smb share

$ df -h
Filesystem                                 Size    Used   Avail Capacity iused ifree 
...
//Guest:@fuse-t-0._smb._tcp.local/crypt   1.1Ti   736Gi   353Gi    68%    193M   92M   68%   /Users/kptsky/Temp/mount
14

Nice! Thanks.

I was doing something with --fuse-flag but in playing with -vv mode, I saw to make it passed properly, I had to do something like --fuse-flag '-o' --fuse-flag 'backend=smb'. I should have read the other. It is a bit confuising:

--fuse-flag stringArray     Flags or arguments to be passed direct to libfuse/WinFsp (repeat if required)
-o, --option stringArray    Option for libfuse/WinFsp (repeat if required)

I will test it when I am at work today (I stull use the kext FUSE at home).

15

I am sorry I totally missed this until the thread was revived.

That is a good question and I don't know. I will have to experiment because I don't think so but I could be wrong.

1 Like
16

@kapitainsky interesting! I am curious what you think and how it compares to the nfs flavor of FUSE-T. Does it seem relatively stable? Any bugs so far? Haven't tried it myself yet, but I am interested as smb seems to be the most reliable protocol on mac these days (ironic, as it was developed for windows...)

17

In case anybody ever needs to install FUSE-T without sudo access here is how:

1 Like