the clone DST path should be at the same mount point as the

Error message

the clone DST path should be at the same mount point as the SRC path

What it means

JuiceFS clone is a server-side (metadata-only) copy: the FUSE mount sends a Clone control message for two inodes, so SRC and DST must live under the same JuiceFS mount point. The command discovers the mount point of SRC and of DST's parent by walking up inodes; if they differ it refuses to run, because a control message can only target one mount.

Source

Thrown at cmd/clone.go:103

		return fmt.Errorf("%s already exists", dst)
	} else if !os.IsNotExist(err) {
		return fmt.Errorf("stat %s: %s", dst, err)
	}
	dstAbsPath, err := filepath.Abs(dst)
	if err != nil {
		return fmt.Errorf("abs of %s: %s", dst, err)
	}

	srcMp, err := findMountpoint(srcAbsPath)
	if err != nil {
		return err
	}
	dstMp, err := findMountpoint(filepath.Dir(dstAbsPath))
	if err != nil {
		return err
	}
	if srcMp != dstMp {
		return fmt.Errorf("the clone DST path should be at the same mount point as the SRC path")
	}
	if strings.HasPrefix(dstAbsPath, path.Clean(srcAbsPath)+"/") {
		return fmt.Errorf("the clone DST path should not be under the SRC path")
	}

	dstParent := filepath.Dir(dstAbsPath)
	dstName := filepath.Base(dstAbsPath)
	dstParentIno, err := utils.GetFileInode(dstParent)
	if err != nil {
		return fmt.Errorf("lookup inode for %s: %s", dstParent, err)
	}
	var cmode uint8
	umask := utils.GetUmask()
	if ctx.Bool("preserve") || runtime.GOOS == "windows" {
		cmode |= meta.CLONE_MODE_PRESERVE_ATTR
	}
	threads := ctx.Int("threads")
	if threads < 1 {

View on GitHub (pinned to c9a67b23e8)

Solutions

Clone to a DST path under the same mount point as SRC
For cross-volume copies, use `juicefs sync` or `cp -r` instead of clone
Check mounts with `juicefs status` / `mount | grep juicefs` and confirm both paths resolve to the same mountpoint
If a nested mount is shadowing the intended path, unmount it or pick a different DST

Example fix

// before
juicefs clone /mnt/jfs-prod/file1 /mnt/jfs-backup/file1
// after
juicefs sync /mnt/jfs-prod/file1 /mnt/jfs-backup/file1   # or clone within one mount
juicefs clone /mnt/jfs-prod/file1 /mnt/jfs-prod/file1.copy

Defensive patterns

Strategy: validation

Validate before calling

if filepath.Dir(absDst) is not under the same juicefs mountpoint as absSrc {
    return errors.New("clone requires SRC and DST on the same JuiceFS mount")
}

Try / catch

if err := runClone(src, dst); strings.Contains(err.Error(), "same mount point") {
    // fall back to `juicefs sync` or plain copy for cross-volume transfer
}

Prevention

Check `mount | grep juicefs` to confirm both paths share one mountpoint
Use `juicefs sync` for cross-volume copies by design
Beware nested mounts shadowing subpaths of the destination
Document mount topology for CI scripts that clone

When it happens

Trigger: Running `juicefs clone /mnt/jfsA/src /mnt/jfsB/dst` (two different JuiceFS volumes), or DST in a plain directory outside any JuiceFS mount while SRC is inside one (findMountpoint for DST then errors first with 148, but two distinct JuiceFS mounts hit this error directly).

Common situations: Two volumes mounted at /mnt/jfs-prod and /mnt/jfs-backup; copying between environments; DST under a nested second mount (e.g. another JuiceFS bind-mounted inside the first); user expects cp-like cross-filesystem behavior.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06). Data as JSON: /api/errors/c92483574e904077. Report an issue: GitHub.