Copy the cwd including symlinks; how?

Help and Support
1

I am trying to copy a directory as fast as possible, and since it contains both very big files, and a lot of them, rclone seems the obvious choice.
Both cp and rsync solve my problem, but they are slow.
I seem to be having issues replicating their behaviour using rclone however.

The invoking process has just set up a tmpfs mountpoint at .., however it has not changed the directory yet meaning the cwd is still pointing at the old directory which I intend to copy into that tmpfs mountpoint.
This poses a problem for rclone right away which trips and errs with Nothing to do as source and destination are the same.
In the source this seems to stem from all copy-esque operations having the allowOverlap flag set to false (it's the last parameter).
Great start, with the check being seemingly hardcoded and no way to override it, but don't fret, Linux has me covered.
So now I try to run rclone /proc/$$/cwd/ $PWD which satisfies rclone's check and also avoids any potential bugs in which rclone might attempt to access a "canonical" path (which is not a thing, please don't attempt that, ever).
Now I run into the symlink issue described below.

What is the problem you are having with rclone?

Symlinks are either not copied (without --links) or rclone err's out entirely presumably (I haven't checked) because it is not allowed to write to a nearby file (lots of assumptions here).
See the full command below.

This errs out with

2026/06/09 08:12:30 CRITICAL: Failed to create file system for "/proc/15469/cwd/": need ".rclonelink" suffix to refer to symlink when using -l/--links

My best guess is that rclone tries to create /proc/15469/cwd.rclonelink to which Linux says "no".
Note also that /proc/15469/cwd/ itself is a symlink, but it's a special symlink because $(readlink /proc/15469/cwd) is $PWD, but cd /proc/15469/cwd will put you in . which is distinct from $PWD in this case.
(just to be clear, by $PWD I mean the directory which you get by traversing from / to where . would be)

Small PoC:

mkdir src
echo foo > src/bar
ln -s baz src/quux

cd src
sudo mount none -t tmpfs ..

# <-- how to copy `.` to `../dst` here, including the symlink?

Run the command 'rclone version' and share the full output of the command.

rclone v1.74.1

  • os/version: debian 11.11 (64 bit)
  • os/kernel: 7.0.11 (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.26.3
  • go/linking: dynamic
  • go/tags: cmount

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

None. Just local to local.

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

rclone copy \
	--progress \
	--inplace --ignore-checksum \
	--multi-thread-streams 16 --transfers 16 \
	--metadata --links \
	/proc/$$/cwd/ "$PWD"

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

; empty config

A log from the command that you were trying to run with the -vv flag

2026/06/09 08:14:20 DEBUG : rclone: Version "v1.74.1" starting with parameters ["/opt/static-rclone/bin/rclone" "copy" "-vv" "--progress" "--inplace" "--ignore-checksum" "--multi-thread-streams" "16" "--transfers" "16" "--metadata" "--links" "/proc/15631/cwd/" "/some/directory"]
2026/06/09 08:14:20 DEBUG : Creating backend with remote "/proc/15631/cwd/"
2026/06/09 08:14:20 NOTICE: Config file "[…]/rclone/rclone.conf" not found - using defaults
2026/06/09 08:14:20 CRITICAL: Failed to create file system for "/proc/15631/cwd/": need ".rclonelink" suffix to refer to symlink when using -l/--links
2

Doesn't look like my theory about trying to create /proc/12345/cwd.rclonelink is quite right.
Instead you can reproduce this by having your source directory be a symlink itself:

mkdir src
echo foo > src/bar
ln -s baz src/quux

# works fine
rclone copy --links --metadata src dst
rm -rf dst

# bails
ln -s src alt-src
rclone copy --links --metadata alt-src/ dst

# also bails (but this is the kind of scenario I need to use as a workaround for the cwd issue)
exec 3< src
rclone copy --links --metadata /proc/$$/fd/3/ dst

Please note that this is the exact thing why rsync treats src and src/ differently.
Expanding on this some more:

mkdir src
echo foo > src/bar
ln -s baz src/quux

cd src
sudo mount none -t tmpfs ..

# this will fail
rclone copy --metadata --links . ../dst-rclone
# this will work
cp -ra . ../dst-rclone

The rclone error message very blatantly tries to canonicalise the path (as I mentioned in the OP, that's basically a bug):

2026/06/09 08:46:35 ERROR : Local file system at /tmp/tmp.xMH4Jd28JE/src: error reading source root directory: directory not found
2026/06/09 08:46:35 ERROR : Attempt 1/3 failed with 1 errors and: directory not found
2026/06/09 08:46:35 ERROR : Local file system at /tmp/tmp.xMH4Jd28JE/src: error reading source root directory: directory not found
2026/06/09 08:46:35 ERROR : Attempt 2/3 failed with 1 errors and: directory not found
2026/06/09 08:46:35 ERROR : Local file system at /tmp/tmp.xMH4Jd28JE/src: error reading source root directory: directory not found
2026/06/09 08:46:35 ERROR : Attempt 3/3 failed with 1 errors and: directory not found
2026/06/09 08:46:35 NOTICE: Failed to copy: directory not found
3

Maybe try making the proc cwd path resolve as a directory, not as the symlink itself:

`rclone copy --links /proc/$$/cwd/. "$PWD"`

The trailing `/.` is the important bit. It should get past treating `/proc/$$/cwd` itself as the symlink that needs a `.rclonelink` companion, while still letting `--links` handle symlinks inside the tree. If that still trips over the local backend, I would treat it as an rclone edge case and use `cp -a . "$PWD"` or `rsync -a ./ "$PWD"/` for this local-to-local step.

4

Same issue. Both with copy as well as copyto:

2026/06/09 14:54:21 CRITICAL: Failed to create file system for "/proc/22905/cwd/.": need ".rclonelink" suffix to refer to symlink when using -l/--links

I mean, yes, I can just not use rclone, but that means waiting for 5min instead of 1min between 3 to 15 times a day, at which point xkcd 1205 lets me spend about a month on that.

5

Maybe a bind mount is worth testing here. If the awkward part is that the only usable name for the old cwd is a /proc/... symlink, you could give it a stable normal path first, for example: mkdir -p /run/user/UID/oldcwd && sudo mount --bind . /run/user/UID/oldcwd, then run rclone copy --links --metadata /run/user/UID/oldcwd/ ../dst. Replace UID with your numeric user id. The bind mount should keep referring to the original directory even after the parent mount changes, while rclone sees an ordinary directory path instead of the magic proc link. Not as neat as an rclone flag for this, but it might keep you on the faster path if cp/rsync are too slow.

6

The invoking process has just set up a tmpfs mountpoint at .., however it has not changed the directory yet meaning the cwd is still pointing at the old directory which I intend to copy into that tmpfs mountpoint.

I don't even understand this sentence.

Can you be a bit more clear, what you mounted where and what you want to copy, both source and target?

$PWD is a variable that changes automatically when you switch between directories, the same like /proc/$$/cwd does.

And you cannot mount something to ..

As this would over-mount your own current $PWD

So, give more concrete examples, please.

7

Bind mounting would circumvent this, yes.
However, that's not solving my problem.
It's kind of like closing a bug report on the Firefox bugzilla with "Chromium doesn't have that issue".
I'm overmounting on purpose to avoid having to deal with moving mounts or keeping temporary mounts around which may need cleanup later on.

8

Yes, yes you can.
The second code block in my first reply has a working example which does work.

Correct.
That is the intended and desired behaviour here.

As stated above, there's a whole code block which is a concrete example which you can run yourself.

$PWD isn't a variable that changes automatically so much as the shell you're working it does set it internally.
The PWD environment variable is contingent on your shell, it is not magic.
On the other hand the cwd symlink is magic, since that one is dynamically provided by the kernel based on the current cwd of the process.

You can actually test this using anything that isn't a shell.
I was going to provide some C code, but Python works just the same:

import os

os.getenv("PWD")
# '/home/user'

os.chdir("..")
os.getcwd()
# '/home'

os.getenv("PWD")
# '/home/user'

I have a directory which contains files in /srv/parent/files.
My process is in /srv/parent/files and mounts a tmpfs onto .., which is /srv/parent.
My process then needs to transfer the data in . (i.e. what was previously /srv/parent/files) to /srv/parent/files.
Effectively it moves copies the directory itself into a tmpfs (for performance reasons) while also shadowing all other directories in /srv/parent.
This is on purpose.

9

That's sounds quite crazy.

I don't even understand what your goal is here and why you are trying it this way.

Good luck :sweat_smile:

10

As expected I can fix my problem by making rclone not canonicalize the path.
This allows me to just refer to . and rclone will happily sync all my files including symlinks from . to ../whatever without any issue whatsoever.

diff --git a/backend/local/local.go b/backend/local/local.go
index 2133279..a3fe6bb 100644
--- a/backend/local/local.go
+++ b/backend/local/local.go
@@ -438,7 +438,7 @@ func NewFs(ctx context.Context, name, root string, m configmap.Mapper) (fs.Fs, e
        if xattrSupported {
                f.xattrSupported.Store(1)
        }
-       f.root = cleanRootPath(root, f.opt.NoUNC, f.opt.Enc)
+       f.root = root;
        f.features = (&fs.Features{
                CaseInsensitive:          f.caseInsensitive(),
                CanHaveEmptyDirectories:  true,