Unnecessary No such file or directory when launching Lima shell

Description

This seems like a corner case, triggered when the macOS host folders are not shared in the way Lima expects, but with another VM-side path.

Steps

mount one path, e.g. /Users/jack/ABC as /home/lima/ABC
go to the said folder, host side

run:

% limactl shell edge-vm 
bash: line 1: cd: /Users/asko/Git/ezb-node: No such file or directory
bash: line 1: cd: /Users/asko: No such file or directory
lima@lima-edge-vm:~$

This is harmless. It's caused by Lima VM (2.3.0-beta.0) attempting to cd to your host side path when a folder has been mounted to the VM with another path.

Work-around

% limactl shell --workdir /home/lima/ABC edge-vm
lima@lima-edge-vm:~/ABC$

Suggestion

To retain the logic that Lima tries to cd to the VM-side equivalent of a mounted folder (which is considerate, though I would personally not expect that), Lima should consult the mount map instead of assuming the path is unchanged.

macOS 27.0
Lima 2.3.0-beta.0

That PWD is a default for LIMA_WORKDIR is a known feature, but I was more curious about the second line.

Wondering why it is trying to find /Users/asko in the VM, instead of the regular /home/asko.guest directory?

EDIT: Never mind, another feature. Not been paying attention.

Update logic for shell workdir #40

If the --workdir does not exist in the guest, we fallback to the host $PWD first before trying the host $HOME

Think the above is missing some details on how the VM was created, I suppose it is either plain or mount-none?

If I recall correctly, the decision was that plain VMs were expected to use ssh instead of lima (limactl shell $LIMA_INSTANCE)

Then you would end up in the guest home by default - although I think you would have to use cd to change the workdir then

EDIT: Maybe use something like this:

https://github.com/fraction/sshcd

ssh lima-minimal
anders@lima-minimal:~$
sshcd lima-minimal:directory
anders@lima-minimal:~/directory$

limactl shell --workdir . minimal
anders@lima-minimal:~$
limactl shell --workdir directory minimal
anders@lima-minimal:~/directory$

LIMA_INSTANCE=minimal LIMA_WORKDIR=. lima
anders@lima-minimal:~$ 
LIMA_INSTANCE=minimal LIMA_WORKDIR=directory lima
anders@lima-minimal:~/directory$

The default workdir doesn't work, when you don't have $PWD (.) mounted in the guest. Neither does the fallback to $HOME (~)

It does work with relative links, though. Or with the template variables like {.Host}. Just not with the host shell expansion.

My project is EdgeVM. It helps configuring Lima VM's as sandboxes, under macOS, for various development needs.

Think the above is missing some details on how the VM was created, I suppose it is either plain or mount-none?

It's neither. The Makefile in the project appends certain mounts to the template YAML. In my understanding, all this is normal Lima VM use. I just don't want to share any host paths (i.e. VM has no /Users/...), because of sandboxing.

If I recall correctly, the decision was that plain VMs were expected to use ssh instead of lima (limactl shell $LIMA_INSTANCE)

I don't find that in documentation, but that's fair. Just wanted to share the finding, since I think it can be fixed without changing the intention. The current behaviour expects mounts to keep their path names. That's not necessarily the case. i.e. mounts.mountPoint are ignored.

ps. I'm editing my repo to reflect the suggestion to use ssh -F, though it becomes a bit longer:

% limactl shell --workdir /home/lima/Abc edge-vm

or using bare ssh:

% ssh -t -F ~/.lima/edge-vm/ssh.config lima-edge-vm "cd /home/lima/Abc && exec \$SHELL -l"

just don't want to share any host paths (i.e. VM has no /Users/...), because of sandboxing.

This is the meaning of the command line option --mount-none, it negates the _default mounts:

mounts:
- location: "~"

# # /tmp/lima is no longer mounted by default since Lima v2.0.
# - location: "{{.GlobalTempDir}}/lima"
#  mountPoint: /tmp/lima
#  writable: true

It probably deserves mentioning as a "third" option*, currently it is only mentioned in the AI docs.

It uses --mount-only .:w and not --mount-none, but anyway. (The default mount is read-only.)

* Third option refers to "machine" mode vs. "plain" mode:

Describe the different major modes of Lima operation #3749

Just wanted to share the finding, since I think it can be fixed without changing the intention. The current behaviour expects mounts to keep their path names.

Yes, that seems reasonable. Currently it only works for plain mode, I believe? The host current directory or the host home must exist in the mounts, or it should skip those host directories...

DEBU[0000] the host home does not seem mounted, so the guest shell will have a different cwd

cmd/limactl/shell.go

mountsContainPath(inst.Config.Mounts, hostCurrentDir) || inst.VMType == limatype.WSL

hostHomeDir != "" && mountsContainPath(inst.Config.Mounts, hostHomeDir)

That is the code that should also include the MountPoint, in case it has been changed (from Location).

The host current directory or the host home must exist in the mounts, or it should skip those host directories...

Oh, that made me realize I omitted some important information (and it's not available in the repo either, by design). Here are my custom mounts:

~/Git/SLED
~/Git/ezb-node

..which cause this to be appended to the YAML that is in the repo.

mounts:
  - location: "~/Git/SLED"
    mountPoint: "{{.Home}}/SLED"
    writable: true
  - location: "~/Git/ezb-node"
    mountPoint: "{{.Home}}/ezb-node"
    writable: true

i.e. that should give enough context to know the use case.

Unfortunately, I am not intending to go in the Lima source to change this. Just reporting, and okay to close the issue if you feel it's not vital enough to fix. :)

That is just fine (we'll fix), thank you for the bug report

I don't find that in documentation

I think it is only in the message shown:

                        if !isLaunchingShell(ctx) {
                                if *inst.Config.Plain {
                                        logrus.Infof("READY. Run `ssh -F %#q %s` to open the shell.", inst.SSHConfigFile, inst.Hostname)
                                } else {
                                        logrus.Infof("READY. Run `%s` to open the shell.", LimactlShellCmd(inst.Name))
                                }
                        }

Maybe not explicitely in the documentation.

https://lima-vm.io/docs/config/plain/#accessing-the-instance

https://lima-vm.io/docs/usage/ssh/

But in this particular case, it was just a bug. The code was expecting the MountPoint to be empty (same as Location)

So that's why it assumes that "/Users/asko/Git/ezb-node" is mounted there, even when it is really at another path...

Once that is fixed, then lima should continue to work, silently.

You would still end up in the home directory by default, though.

You would still end up in the home directory by default, though.

That's actually welcome, and expected.

Thanks for taking this. Leaving for other projects...

@afbjorklund

Hi @afbjorklund, since #5522 was closed, would it be ok if I pick this up?

My plan, based on @jandubois's review there: instead of only checking that the host dir is under a mount's location and then running cd <host path> in the guest, map it through the mount (mountPoint + the path relative to location) for both the current dir and the home dir fallback, and skip the cd when the dir isn't under any mount. I'd add a table test for the mapping (remapped mountPoint, nested dir, / mount, unmounted dir) and check it on macOS with a remapped mount.

shell: cd to the guest path of remapped mounts

Navigation Menu

Repository navigation

Unnecessary `No such file or directory` when launching Lima shell #5520

Description

Steps

Work-around

Suggestion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unnecessary No such file or directory when launching Lima shell #5520

Description

Description

Steps

Work-around

Suggestion

Activity

afbjorklund commented on Sep 20, 2026

afbjorklund commented on Sep 20, 2026

finalyards commented on Sep 20, 2026

afbjorklund commented on Sep 20, 2026

afbjorklund commented on Sep 20, 2026

finalyards commented on Sep 20, 2026

afbjorklund commented on Sep 20, 2026

afbjorklund commented on Sep 20, 2026

finalyards commented on Sep 21, 2026

saswatsam786 commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Unnecessary `No such file or directory` when launching Lima shell #5520