Same mount on different machines shows different files

I've got a head scratcher and hoping this group can help me figure out what I'm missing. I suspect it is a glaring user error :slight_smile:

First, my setup (like many of you too) is a little complicated. I use rclone to mount a google drive. most of the contents of that drive is encrypted using encfs. Usually when I mount, I also do a union (either through unionfs or an rclone union) with a matching local folder (also using encfs).
It usually looks like this:

google drive encrypted --> ~/.cloud
encfs ~/.cloud decrypted --> ~/cloud
local encrypted --> ~/.local
encfs ~/.local decrypted --> ~/local
union of ~/cloud and ~/local --> ~/media

I mount this setup on a few macOS machines and on several Ubuntu machines (sometimes on the same machine but under two different users)

On Ubuntu, under a specific user, I mount my google drive with a path, like this:

barsmusicrw:encmedia/XgksGASDkelsFDF-Fkdk4skf --> ~bar/.cloud

(barsmusicrw is for that specific user, mount is a read/write ... that encrypted text is made up for this post, but is similar in style and length to my encfs filenames)

Elsewhere, I mount the same google dive this way:

gdrive:encmedia --> ~foo/.cloud

User Foo wants the entirety of encmedia while user Bar only wants the contents of the decrypted XgksGASDkelsFDF-Fkdk4skf folder.

For the sake of this post, let's say XgksGASDkelsFDF-Fkdk4skf decrypts to Tunes

Note that none of these are using caching. In all instance, I use these flags:
--config=$R_CONFIG --dir-cache-time 1h --drive-chunk-size 32M --log-level INFO --timeout 1h --umask 002 --daemon
(where $R_CONFIG is the path to the config file)

config for user Bar
type = drive
client_id = redacted
client_secret = redacted
scope = drive
token = {"access_token": redacted}
root_folder_id = AyEskifEovsFVSEf

config for user Foo
type = drive
client_id = redacted
client_secret = redacted
token = {"access_token": redacted}
chunk_size = 16M
root_folder_id = AyEskifEovsFVSEf

To my eye, they are nearly identical. They actually use the same access tokens, FWIW

Here's the rub:
For user Bar, I see about 100 files in both ~/.cloud and ~/cloud. I see the same number of files in the web interface of Google Drive too. In google Drive, the encrypted filenames match up. EG: what I see in ~/.cloud is what I see in drive/XgksGASDkelsFDF-Fkdk4skf

For user Foo:
in both ~/.cloud and ~/cloud I see 5 files. I've tried unmounting and remounting, I've rebooted...tried other machines using Foo's config.

Anyone have any idea what Bar is seeing the right files but Foo isn't? Could it be some sort of caching that I'm not accounting for? It's been over 24 hours since the last rclone sync so I'd think my 1 hour timeout and dir-cache-time wouldn't be the issue.

I'd be grateful for any tips - this one was a hard to document and explain as it is to wrap my head around :rofl:

I will try to come back and digest this in more detail later, but as just a quick skimp I notice that Foo does not have a defined scope like Bar:
scope = drive

This is usually something that is always a part of any Gdrive config (generated by rclone config). I really don't know what this might default to if it is left undefined because I have never tried. I would assume it's "drive" that is default, but I would just test this quick before anything else since because it could definitely affect what you can access...

Also clarify please... the 5 files you see with Foo, are they 5 of the files you should be seeing? Or are they something else?

Final note: Are you observing this through a crypt layer? Because a very typical problem is that if you try to view either uncrypted files or crypted files (but with a different key or config to what your crypt remote is using) then they will fail to decrypt and the resulting "garbage" will not even display (rclone log will have lots of errors if this should be the case). It seems like you have a good handle on crypt works, but I want to make sure it's not one of the these common repeat-issues :slight_smile:

Can you try using rclone ls on the underlying remotes and see whether you get the same answer there?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.