Cannot assign requested address, vfs reader failed to write to cache file

Help and Support
1

Almost every night (around 2am) the following error occurs, it doesn't seem to affect anything at least that I am aware off but this will occur to about 4 files every night.

vfs cache: failed to download: vfs reader: failed to write to cache file: Post https://content.dropboxapi.com/2/files/download": dial tcp [2620:100:6035:14::a27d:550e]:443: connect: cannot assign requested address

I also have two mounts that have almost identical arguments, with the exception to the remote, mount, log, cache and rc-addr values, every other argument is the same and yet this only occurs on one of my mounts. Any idea's what could be causing this? I haven't been able to get a debug log as this doesn't occur every night and I don't have logrotate setup yet.

rclone v1.62.2

  • os/version: ubuntu 20.04 (64 bit)
  • os/kernel: 4.18.0-425.3.1.el8.x86_64 (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.20.2
  • go/linking: static
  • go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Dropbox

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone mount dcrypt-shows: /media/shows \
    --allow-other \
    --dir-cache-time 5000h \
    --log-file /logs/rclone-shows.log \
    --log-level ERROR \
    --umask 002 \
    --cache-dir /cache/shows \
    --vfs-cache-mode full \
    --vfs-cache-max-size 1000G \
    --vfs-write-back 1m \
    --vfs-cache-max-age 5000h \
    --vfs-fast-fingerprint \
    --dropbox-batch-mode sync \
    --dropbox-batch-size 100 \
    --dropbox-chunk-size 128m \
    --tpslimit 12 \
    --tpslimit-burst 0 \
    --rc \
    --rc-addr 127.0.0.1:5577 \
    --rc-user <redacted> \
    --rc-pas <redacted>

The rclone config contents with secrets removed.

[db-shows]
type = dropbox
client_id = <redacted>
client_secret = <redacted>
token = <redacted>

[dcrypt-shows]
type = crypt
remote = db-shows:
password = <redacted>
password2 = <redacted>
filename_encryption = standard
directory_name_encryption = true
filename_encoding = base32768

[db-films]
type = dropbox
client_id = <redacted>
client_secret = <redacted>
token = <redacted>

[dcrypt-films]
type = crypt
remote = db-films:
password = <redacted>
password2 = <redacted>
filename_encryption = standard
directory_name_encryption = true
filename_encoding = base32768
3

Can you post the other mount command?

4

Looks like networking error on your machine with IPV6 address not being able to make a connection. I do not think it is an issue that can cause much trouble given it happens rarely but you could try to use IPv4 exclusively by using this flag in your mount:

--bind string Local address to bind to for outgoing connections, IPv4, IPv6 or name

1 Like
5

Thanks, I'll add this now and see if I get the error in the next day or two.

The arguments are basically identical except for the parts I mentioned. It's possible that I'm only seeing this error on my tv mount because it's used more by family/friends (up to 4 people most nights) while my movies mount might see 2-3 people a week. Here's the mount command

rclone mount dcrypt-films: /media/films \
    --allow-other \
    --dir-cache-time 5000h \
    --log-file /logs/rclone-films.log \
    --log-level ERROR \
    --umask 002 \
    --cache-dir /cache/films \
    --vfs-cache-mode full \
    --vfs-cache-max-size 1000G \
    --vfs-write-back 1m \
    --vfs-cache-max-age 5000h \
    --vfs-fast-fingerprint \
    --dropbox-batch-mode sync \
    --dropbox-batch-size 100 \
    --dropbox-chunk-size 128m \
    --tpslimit 12 \
    --tpslimit-burst 0 \
    --rc \
    --rc-addr 127.0.0.1:5576 \
    --rc-user <redacted> \
    --rc-pas <redacted>
6

ok - let'see - but IMHO random network problems are not disaster or even problem - rclone can deal with it - very often it is normal - my ISP always flips early morning. Why? I have no clue - maybe they have something rebooted everyday?

7

I'm not too worried about the error, just found it strange that I received this with dropbox but never recieved any error regarding ipv6 ip's with google, the main difference between this setup and my old google setup is that I used an upload script, whereas this time I'm using the mount to upload, but hopefully in the next 2 days I'll know whether or not --bind solved the problem.

Once every few weeks my ISPs modem/hub randomly restarts, same happens to family and friends who are on the same ISP, it's only down for like a 30-60 seconds, so I assume they're updating the firmware or something. If it was everyday I'd consider it an issue and report it to my ISP but if its weekly bi-weekly or monthly, then I pretty much ignore it.

Anyway, I appreciate the help and I will report back as soon as I can.

1 Like
8

Please report back what you find - good or bad or even if suggestion was useless - it can only help to make things better.

1 Like
9

Got the following error, although I didn't get as many errors this time which is good I suppose.

vfs cache: failed to download: vfs reader: failed to write to cache file: read tcp 172.18.0.25:59967->162.125.85.14:443: read: connection reset by peer

For now it's not causing any issues but I'll continue looking into it. I'll report back if I figure it out.

10

That's just a networking issue. I would generally ignore those. If you get them constantly, check out your networking setup.

11

I'm only getting 1 or 2 every few days, so I'll just ignore it for now.

Thanks.

12

Those messages tend to be problematic / challenging to figure out.

I had timeouts for some period of time and it took me quite a bit of time to finally realize Verizon FIOS was giving me a new IPV6 address without a very specific setting in my router's configuration. That change in IP would cause my existing IPV6 connections to time out/reset since the IP address changed.

I blamed rclone/various things along the way and finally realize the root cause and it was a simple checkbox to fix and not related to my server/rclone/etc.

The oddball issues are the toughest to generally figure out and seem so simple once you do figure it out.

1 Like
13

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