Bug 1842371

Summary: Can't mount sshfs using vagrant
Product: [Fedora] Fedora Reporter: Ludovic Hirlimann [:Paul-muadib] <ludovic>
Component: vagrant-sshfsAssignee: Dusty Mabe <dustymabe>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: dalley, dustymabe, lmohanty, madam, pvalena, strzibny, thrcka, vondruch
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: vagrant-sshfs-1.3.5-1.fc32 vagrant-sshfs-1.3.5-1.fc31 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-08 01:04:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Vagrant file that issues the problem.
none
end of the output when adding --debug to SSH_AUTH_SOCK= vagrant up
none
file from my .vagrant directory none

Description Ludovic Hirlimann [:Paul-muadib] 2020-06-01 06:08:34 UTC
Created attachment 1694015 [details]
Vagrant file that issues the problem.

Description of problem:

I have a very simple Vagrant file (see attached). That wants to mount the local directory.

this used to work when I used :
SSH_AUTH_SOCK= vagrant up

Now it doesn't and spurs errors


Version-Release number of selected component (if applicable):
vagrant-sshfs-1.3.4-1.fc32.noarch
vagrant-libvirt-doc-0.0.45-4.fc32.noarch
vagrant-libvirt-0.0.45-4.fc32.noarch
vagrant-2.2.9-1.fc32.noarch
libvirt-daemon-driver-network-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-nwfilter-6.1.0-3.fc32.x86_64
libvirt-gconfig-3.0.0-2.fc32.x86_64
libvirt-daemon-driver-nodedev-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-mpath-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-core-6.1.0-3.fc32.x86_64
rubygem-fog-libvirt-0.5.0-5.fc32.noarch
libvirt-daemon-config-network-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-sheepdog-6.1.0-3.fc32.x86_64
vagrant-libvirt-doc-0.0.45-4.fc32.noarch
libvirt-bash-completion-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-gluster-6.1.0-3.fc32.x86_64
rubygem-ruby-libvirt-0.7.1-8.fc32.x86_64
libvirt-glib-3.0.0-2.fc32.x86_64
libvirt-daemon-driver-storage-logical-6.1.0-3.fc32.x86_64
libvirt-libs-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-iscsi-direct-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-rbd-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-scsi-6.1.0-3.fc32.x86_64
libvirt-gobject-3.0.0-2.fc32.x86_64
libvirt-daemon-driver-qemu-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-disk-6.1.0-3.fc32.x86_64
libvirt-daemon-kvm-6.1.0-3.fc32.x86_64
vagrant-libvirt-0.0.45-4.fc32.noarch
libvirt-daemon-driver-storage-iscsi-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-6.1.0-3.fc32.x86_64
libvirt-client-6.1.0-3.fc32.x86_64
libvirt-devel-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-secret-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-storage-zfs-6.1.0-3.fc32.x86_64
libvirt-daemon-6.1.0-3.fc32.x86_64
libvirt-daemon-driver-interface-6.1.0-3.fc32.x86_64


How reproducible: All the time


Steps to Reproduce:
1. Setup vagrant
2. Try to start vagrant


Actual results:

I have a running VM but no access to my local files project files.

Expected results:

vagrant "mount" the local FS on the VM.

Additional info:

This is what I get as an error message. adding --debug shows more infor but I didn't find anything relevant.

Mounting SSHFS shared folder via slave SSHFS mount failed. Please
look at the below STDERR output from the processes that were run.

SSH command:

load pubkey "/home/ludovic/Documents/src/3liz/lizmap-box/.vagrant/machines/centos/libvirt/private_key": invalid format
Warning: Permanently added '192.168.122.150' (ECDSA) to the list of known hosts.
sudo: sshfs: command not found


SFTP command:






Sorry If it's filed in the wrong component - I was unsure which one to file in.

Comment 1 Ludovic Hirlimann [:Paul-muadib] 2020-06-01 06:10:54 UTC
Created attachment 1694016 [details]
end of the output when adding --debug  to SSH_AUTH_SOCK= vagrant up

Journalctl doesn't have anything related to either vagrant ssh, or sshfs only has these bits :

[ludovic@saraan]~% journalctl -e |grep libvirt
Jun 01 08:05:30 saraan libvirtd[5705]: Unable to open vhost-net. Opened so far 0, requested 1
Jun 01 08:05:30 saraan systemd[1]: libvirtd.service: Found left-over process 1610 (dnsmasq) in control group while starting unit. Ignoring.
Jun 01 08:05:30 saraan systemd[1]: libvirtd.service: Found left-over process 1611 (dnsmasq) in control group while starting unit. Ignoring.
Jun 01 08:05:30 saraan audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=libvirtd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 01 08:05:31 saraan dnsmasq[1610]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Jun 01 08:05:31 saraan dnsmasq-dhcp[1610]: read /var/lib/libvirt/dnsmasq/default.hostsfile
Jun 01 08:08:07 saraan systemd[1]: libvirtd.service: Succeeded.
Jun 01 08:08:07 saraan audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=libvirtd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Comment 2 Ludovic Hirlimann [:Paul-muadib] 2020-06-01 06:13:02 UTC
Created attachment 1694017 [details]
file from my .vagrant directory

Comment 3 Ludovic Hirlimann [:Paul-muadib] 2020-06-01 06:13:59 UTC
Anything else you need to reproduce ?

Comment 4 Pavel Valena 2020-06-01 15:08:44 UTC
This is caused by upstream Vagrant change, but the error is in vagrant-sshfs plugin. Fix:

  https://github.com/dustymabe/vagrant-sshfs/pull/111

Comment 5 Daniel Alley 2020-06-14 03:31:20 UTC
I'd be glad to help test this, it is blocking myself and a couple of team members as well.

Comment 6 Pavel Valena 2020-06-15 13:18:24 UTC
(In reply to Daniel Alley from comment #5)
> I'd be glad to help test this, it is blocking myself and a couple of team
> members as well.

The fix (although experimental) I've linked is not yet linked in the upstream, but you can try it here:

https://copr.fedorainfracloud.org/coprs/pvalena/vagrant/


Dusty, will you create the update?

Comment 7 Dusty Mabe 2020-06-29 06:04:07 UTC
Assuming Pavel is correct and https://github.com/dustymabe/vagrant-sshfs/pull/111 fixes the problem then vagrant-sshfs-1.3.5-1.fc32 should fix it.

Comment 8 Fedora Update System 2020-06-29 06:09:39 UTC
FEDORA-2020-d072f13ef6 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d072f13ef6

Comment 9 Fedora Update System 2020-06-29 06:09:40 UTC
FEDORA-2020-11f1015437 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-11f1015437

Comment 10 Ludovic Hirlimann [:Paul-muadib] 2020-06-29 12:38:49 UTC
(In reply to Fedora Update System from comment #8)
> FEDORA-2020-d072f13ef6 has been submitted as an update to Fedora 32.
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d072f13ef6

sudo dnf update --enablerepo=updates-testing --refresh doesn't show the package, am I doing something wrong ?

Comment 11 Vít Ondruch 2020-06-29 12:51:57 UTC
(In reply to Ludovic Hirlimann [:Paul-muadib] from comment #10)
> sudo dnf update --enablerepo=updates-testing --refresh doesn't show the
> package, am I doing something wrong ?

The update is still in "pending -> testing" state, so it was not pushed into testing repository yet. If you are impatient, you should be able to take the package for test ride from Koji:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1534560

Comment 12 Fedora Update System 2020-06-30 00:55:08 UTC
FEDORA-2020-11f1015437 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-11f1015437`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-11f1015437

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2020-06-30 01:13:09 UTC
FEDORA-2020-d072f13ef6 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d072f13ef6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d072f13ef6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2020-07-08 01:04:08 UTC
FEDORA-2020-d072f13ef6 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 15 Fedora Update System 2020-07-08 01:05:41 UTC
FEDORA-2020-11f1015437 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.