Cannot list contents of rclone mount - I/O error caused by directory named `.`

rclone lsd crypt:/ works fine.

When I attempt to mount the same share via

rclone mount --log-level DEBUG --allow-non-empty --allow-other --max-read-ahead 200M --drive-chunk-size 128M --checkers 40 --dir-cache-time 30m --transfers=32 crypt: /home/user/rclone

any attempt to list the contents of the directory /home/user/rclone fails with the error message:

ls: reading directory ‘rclone’: I/O error

When that error happens, I see the following output from the “mount” command:

2019/02/07 17:09:45 DEBUG : /: Attr:
2019/02/07 17:09:45 DEBUG : /: >Attr: attr=valid=1m0s ino=0 size=0 mode=drwxr-xr-x, err=
2019/02/07 17:09:45 DEBUG : /: ReadDirAll:
2019/02/07 17:09:45 DEBUG : : Re-reading directory (27h39m48.69929782s old)
2019/02/07 17:09:46 DEBUG : oblnuslpfer7n4vrseo5s1svvs: Skipping undecryptable dir name: Bad PKCS#7 padding - not all the same
2019/02/07 17:09:46 DEBUG : mmcljiv7nbck26c1a16sc5rgus: Skipping undecryptable dir name: Bad PKCS#7 padding - too long
2019/02/07 17:09:46 DEBUG : duifoftrp05tcvnivp1qoqcmi8: Skipping undecryptable dir name: Bad PKCS#7 padding - too long
2019/02/07 17:09:46 DEBUG : 043cqpc8rkn0jvccoaldr792bc: Skipping undecryptable dir name: Bad PKCS#7 padding - too long
2019/02/07 17:09:46 DEBUG : up5dm2fj19f3qjmd3tsm6roqb8: Skipping undecryptable dir name: Bad PKCS#7 padding - too long
2019/02/07 17:09:46 DEBUG : 2f00ni6569sro0cg2493p2b9bs: Skipping undecryptable dir name: Bad PKCS#7 padding - too long
2019/02/07 17:09:46 DEBUG : /: >ReadDirAll: item=26, err=

Here is my redacted .rclone.conf:
type = drive
client_id = [redacted]
client_secret = [redacted]
token = {“access_token”:"[redacted]",“token_type”:“Bearer”,“refresh_token”:"[redacted]",“expiry”:“2019-02-07T14:13:13.781805284-07:00”}
team_drive =

type = crypt
remote = foo:/crypt
filename_encryption = standard
password = [redacted]
password2 = [redacted]

What’s your rclone version show?

–max-read-ahead 200M --checkers 40 --transfers=32 all do nothing on a mount command so they can be removed as well. (max-read-ahead does something but only if you are compiling a custom kernel on your OS).

I have tried with rclone versions 1.39, 1.42, and 1.44

I picked up those flags from this forum forever ago, but if they do nothing, I’m happy to stop passing them! :slight_smile:

Just for fun, can you grab the latest stable ? That’s 1.45.

That error usually relates back to the passwords being off, but you are using the same machine/account to run the mount as you are doing the rclone mount?

Yes, the lsd and the mount have been run on the same machines as the same username in 3 different cases, and in each case commands like ls and lsd return results just fine, while mount just utterly fails. All of this was working a few weeks ago, but I went out of town and came back to none of my mounts working.

I’ll give 1.45 a shot now.

Can you share the lsd output as well?

No go with 1.45 either.

lsd gives:


Which, to the best of my recollection, is the correct contents of that share.

Are you doing directory encryption as well?

directory_name_encryption = true ?

Is it a team drive as well?

It is not a team drive, but I am doing directory encryption; while I don’t have that flag you mentioned specified anywhere, I believe this is why I have a password and a password2 in my .rclone.conf

Hmm, yeah as my conf looks like:

type = crypt
remote = GD:media
filename_encryption = standard
password = somepassword
password2 = somepassword
directory_name_encryption = true

As I do both.

OK, after adding --log-level DEBUG to the lsd command, I realized that it complains about the same 8 entries:


After some thought, I’m pretty sure those are 8 completely empty directories in the crypt: share - I think they’re from the first attempt at setting up rclone, when I made the directories in a crypt but didn’t bother to remember the password I had used, because it was just a test to see what the items end up looking like on the Google Drive side. So those directories mount is whinging about are completely useless folders that have nothing in them. I have deleted those directories from the Google Drive side.

Oh, that makes sense and would do it.

Still doesn’t explain why lsd can list the directory, but mount gives an I/O error?
(The mount I/O error persists after deleting those directories)

Here’s the new DEBUG from rclone mount, without those directories:

2019/02/07 17:42:00 DEBUG : Using config file from "/home/user/.rclone.conf"
2019/02/07 17:42:00 DEBUG : rclone: Version "v1.39" starting with parameters ["rclone" "mount" "--log-level" "DEBUG" "--allow-non-empty" "--allow-other" "--drive-chunk-size" "128M" "--dir-cache-time" "30m" "crypt:" "/home/user/rclone"]
2019/02/07 17:42:01 INFO  : Encrypted drive 'crypt:': Modify window is 1ms
2019/02/07 17:42:01 DEBUG : Encrypted drive 'crypt:': Mounting on "/home/user/rclone"
2019/02/07 17:42:01 mount helper error: fusermount: failed to open /etc/mtab: Permission denied
2019/02/07 17:42:01 DEBUG : vfs cache root is "/home/user/.cache/rclone/vfs/crypt"
2019/02/07 17:42:01 DEBUG : : Root:
2019/02/07 17:42:01 DEBUG : : >Root: node=/, err=<nil>
2019/02/07 17:42:01 DEBUG : Google drive root 'crypt': Checking for changes on remote
2019/02/07 17:42:01 DEBUG : Google drive root 'crypt': All changes were processed. Waiting for more.

What if you lsd on both the unencrypted version and the crypted one? Do you get the same directories?

felix@gemini:~$ rclone lsd GD:media
          -1 2018-06-30 12:55:49        -1 d93daonsmv845k5s40knr5mf4s
          -1 2018-06-17 09:16:39        -1 s1n6gn87oo537vvls13nahl6co
          -1 2017-04-18 16:14:26        -1 smu5ej34ujbdoip1cm3mlk92q4
          -1 2018-06-17 10:24:02        -1 tnvepu36qiohcun8v84ddhsam0
          -1 2018-12-28 10:02:24        -1 u8pnnsdsoh6h0mud3ir6jcv4js
felix@gemini:~$ rclone lsd gcrypt:
          -1 2018-06-17 10:24:02        -1 Movies
          -1 2018-12-28 10:02:24        -1 Music
          -1 2018-06-17 09:16:39        -1 Radarr_Movies
          -1 2017-04-18 16:14:26        -1 TV
          -1 2018-06-30 12:55:49        -1 TV_Ended

One of them only shows up when I do lsd on the non-crypt share; I’ve correlated them based on the date below:

          -1 2019-01-22 04:51:59        -1 1o...sc0c  -> ???
          -1 2017-12-28 16:20:20        -1 1v...55ns  -> documents
          -1 2018-05-21 08:15:41        -1 42...i1vs  -> zpool
          -1 2017-07-30 08:26:39        -1 b5...cbco  -> tech
          -1 2018-11-28 06:29:09        -1 bk...01jc  -> tyt
          -1 2018-07-24 04:43:09        -1 bm...6fj0  -> data
          -1 2017-12-24 21:45:42        -1 cf...l618  -> youtube
          -1 2017-07-30 08:05:13        -1 g3...1kk4  -> pictures
          -1 2017-12-28 16:12:22        -1 hk...g7u8  -> podcasts
          -1 2017-12-25 06:40:33        -1 i1...tqe0  -> nontech
          -1 2018-12-20 20:14:36        -1 pu...r8lg  -> logs

The one marked as ??? doesn’t show up under lsd crypt:, only lsd foo:/crypt

OK, 1.45 definitely helped uncover this mystery a little bit. The one marked as ??? above DOES show up in 1.45’s lsd output:

-1 2019-01-22 04:51:59 -1 .

That is, it’s a directory named “.”!!

I have no idea where that came from (I can guess, but I had no idea it was even possible to create something named .), but I assume this is probably what is choking up an attempt to ls the directory when it’s mounted?

Sure enough - deleting the . directory’s contents and then the directory itself fixed my mount. Thanks for helping me stumble into that solution!

updated the post title to indicate the solution, for other people who may be suffering from this later on.

Excellent. Happy you got it solved!