Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mounting: Mount source path does not exist (non snap, linux, qemu) #3462

Open
v4nderstruck opened this issue Apr 5, 2024 · 5 comments
Open

Comments

@v4nderstruck
Copy link

Describe the bug
Hi, I'm trying to mount a directory and multipass fails with "Mount source path ... does not exist."
I have built multipass from source (running on Manjarom, used the AUR package https://aur.archlinux.org/packages/canonical-multipass ) and other functionalities seem to work fine (creating VMs, shell...)

To Reproduce
for example, I try mounting my neovim config dir multipass mount /home/v4nderstruck/.config/nvim dev:/home/ubuntu/.config/nvim

Expected behavior
Mounting should work

Logs
Nothing really usefull in daemon logs. I set it to trace and there is no report (except certificate validation) when mounting...

Mouting with Command with -vvvv

[2024-04-05T11:47:48.375] [debug] [mount cmd] /home/v4nderstruck/.cache/yay/canonical-multipass/src/multipass/src/client/cli/cmd/mount.cpp:234 parse_args(): adding default uid mapping
[2024-04-05T11:47:48.375] [debug] [mount cmd] /home/v4nderstruck/.cache/yay/canonical-multipass/src/multipass/src/client/cli/cmd/mount.cpp:274 parse_args(): adding default gid mapping
mount failed: Mount source path "/home/v4nderstruck/.config/nvim" does not exist.

And I have part of the strace where things may be interesting. Should not be a permission issue and the directory seems to exist.

....
access("/home/v4nderstruck/.config/nvim", F_OK) = 0                                                                                                                                          
statx(AT_FDCWD, "/home/v4nderstruck/.config/nvim", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0777, stx_size=4096
, ...}) = 0                                                                                                                                                                                  
access("/home/v4nderstruck/.config/nvim", R_OK) = 0     

Additional info

  • OS: Manjaro
multipass   1.13.0-dev.0+gef361f9fb
multipassd  1.13.0-dev.0+gef361f9fb
Name:           dev
State:          Running
Snapshots:      0
IPv4:           10.85.104.56
Release:        Ubuntu 22.04.4 LTS
Image hash:     304983616fcb (Ubuntu 22.04 LTS)
CPU(s):         6
Load:           1.04 0.28 0.09
Disk usage:     1.4GiB out of 33.8GiB
Memory usage:   188.7MiB out of 7.7GiB
Mounts:         --

local driver qemu

Additional context
Add any other context about the problem here.

@v4nderstruck v4nderstruck added bug needs triage Issue needs to be triaged labels Apr 5, 2024
@ricab
Copy link
Collaborator

ricab commented Apr 5, 2024

Hi @v4nderstruck, that is not really a supported way of running Multipass, but if everything else seems to work, perhaps AppArmor is denying visibility of that directory to the Multipass daemon? Do you see anything in dmesg | grep apparmor=\"DENIED\"? Does if work if there when the source path does not involve directories/files starting with dot?

@ricab
Copy link
Collaborator

ricab commented Apr 5, 2024

BTW, others seemed to have had issues with the QEMU version from the AUR package: #3441 (comment) . But I doubt that is related to your issue.

@v4nderstruck
Copy link
Author

Hi, I have no apparmor running and regardless of whether the path has a "." or not, it does not work.

apparmor module is loaded.                                                                
apparmor filesystem is not mounted.

any other ideas?

@ricab
Copy link
Collaborator

ricab commented Apr 8, 2024

Hi @v4nderstruck, what compiler/version did you use to build? I ask because our CMake may be allowing compilers without full standard C++17 support yet (requiring only -std=C++1z). If that is your case, it is possible that you didn't have full compliant std::filesystem library support yet. We have had cases of compilers with incomplete C++17 support causing runtime issues in the past.

@townsend2010 townsend2010 added question and removed needs triage Issue needs to be triaged labels Apr 16, 2024
@townsend2010
Copy link
Collaborator

Hi @v4nderstruck!

Could you please provide the answers to the question @ricab asked? If we don't hear back from you soon, we will close this issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants