Error when using sshfs_opts_append: "-o nonempty"

Question

Error when using sshfs_opts_append: "-o nonempty"

Zlopez opened this issue 6 years ago · 18 comments

When trying to run vagrant up with my Vagrantfile I'm getting this error:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

# Update sysconfig
sed -i 's/\(HOSTNAME=\).*/\1anitya-dev.example.com/' /etc/sysconfig/network

# Update DNS
sed -i 's/\(DHCP_HOSTNAME=\).*/\1"anitya-dev"/' /etc/sysconfig/network-scripts/ifcfg-*

# Set the hostname - use hostnamectl if available
echo 'anitya-dev.example.com' > /etc/hostname
if command -v hostnamectl; then
  hostnamectl set-hostname --static 'anitya-dev.example.com'
  hostnamectl set-hostname --transient 'anitya-dev.example.com'
else
  hostname -F /etc/hostname
fi

# Prepend ourselves to /etc/hosts
grep -w 'anitya-dev.example.com' /etc/hosts || {
  sed -i'' '1i 127.0.0.1\tanitya-dev.example.com\tanitya-dev' /etc/hosts
}

# Restart network
service network restart


Stdout from the command:

/usr/bin/hostnamectl


Stderr from the command:

Redirecting to /bin/systemctl restart network.service
Failed to restart network.service: Unit network.service not found.

Without the option sshfs_opts_append: "-o nonempty" the vagrant up works fine.

OS: Fedora Silverblue 29
vagrant: 2.1.2
vagrant-sshfs: vagrant-sshfs-1.3.1-2.fc29.noarch

Answer 1 · 2018-11-02T08:38:08.000Z

Now it's happening even without the option sshfs_opts_append: "-o nonempty".

Answer 2 · 2018-11-02T13:33:36.000Z

hmm. I know of a bug that is currently in testing where booting a fedora 29 vagrant box would fail because we switched to Networkmanager. I wouldn't expect the same bug to affect a fedora 28 vagrant box. It might be worth trying vagrant-2.1.2-3.fc29 in updates-testing.

Answer 3 · 2018-11-02T13:37:54.000Z

By the way. I suspect you'd get that same error even without sshfs.

I imagine what you did here is up your box then halt it at some point and you are re-uping it again after it has been fully updated. That shouldn't break.

Answer 4 · 2018-11-02T13:42:39.000Z

are you sure you weren't using fedora/29-cloud-base ?

Answer 5 · 2018-11-02T13:54:46.000Z

Sorry this image is not exactly the same I'm using on my machine. Yes, I'm using fedora/29-cloud-base.

I have the vagrant-2.1.2-3.fc29 installed, I gave you karma yesterday.

Answer 6 · 2018-11-02T14:31:12.000Z

vagrant-2.1.2-3.fc29 should fix it. Are you saying you are still seeing errors ?

Answer 7 · 2018-11-02T14:41:20.000Z

My bad, I have vagrant-2.1.2-2.fc29.noarch.

Answer 8 · 2018-11-02T14:43:26.000Z

But it's the newest I got yesterday from testing.

Answer 9 · 2018-11-02T14:56:13.000Z

Did rpm-ostree upgrade and there was newer. I will restart and test it.

Answer 10 · 2018-11-02T15:06:13.000Z

Ok, I checked with the newest version and the issue is not really with -o nonempty.

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

SSH command:

Warning: Permanently added '192.168.121.133' (ECDSA) to the list of known hosts.
fuse: unknown option(s): `-o nonempty'


SFTP command:

Answer 11 · 2018-11-02T15:07:26.000Z

After commenting out this option the vagrant up is working.

Answer 12 · 2018-11-02T18:10:29.000Z

ok so this issue is related to sshfs_opts_append: "-o nonempty" not working properly then? can I get you to re-add the option back and run vagrant sshfs --unmount && vagrant sshfs --debug

Answer 13 · 2018-11-03T13:05:51.000Z

Tried to run with vagrant sshfs --unmount && vagrant sshfs --debug and here is the output: https://paste.fedoraproject.org/paste/EAWE8b70OMgU7CgK5WX4IQ

Answer 14 · 2018-11-04T15:48:23.000Z

Here is the relevant command:

DEBUG sshfs_mount: ssh cmd: /usr/bin/ssh -o StrictHostKeyChecking=no  -o ServerAliveInterval=30  -o User=vagrant -o Port=22 -o UserKnownHostsFile=/dev/null  -F /dev/null  -o "IdentityFile=\"/var/home/zlopez/git/anitya/.vagrant/machines/anitya/libvirt/private_key\""  192.168.121.184 "sudo -E sshfs :/var/home/zlopez/git/anitya /home/vagrant/devel -o allow_other  -o noauto_cache  -o slave  -o nonempty "

Looks normal to me. I really don't know why it's not working. How old is the OS of the vagrant box? Does man sshfs inside the VM show a nonempty option?

Also noting here that I'm not able to reproduce locally (fedora 27).

Answer 15 · 2018-11-04T18:15:05.000Z

I'm running Fedora 29 Silverblue and the vagrant is using fedora/29-cloud-base.

Answer 16 · 2018-11-05T02:16:37.000Z

Odd. I really don't know what the issue is. I am currently not yet on f29 but I can verify that on my f27 system a f29-cloud-base vagrant box works fine with that option. I guess for now you have a workaround so you're ok.

Answer 17 · 2018-11-05T02:36:11.000Z

Actually I was able to reproduce.. It looks like the version of fuse inside f29 (fuse3) doesn't accept that option any longer. I'm not sure why.

I don't see much that we can do here in vagrant-sshfs, though. So probably just close this issue out.

Answer 18 · 2018-11-06T09:13:17.000Z

Reported on fedora bugzilla - https://bugzilla.redhat.com/show_bug.cgi?id=1646385

Closing this issue.