Protocol error when using strip over shared folders.

[Alex Barker]

Steps to reproduce: Share a folder to a Linux guest. Copy a dll file to the share folder. (I used the taskschd.dll to test) On the linux guest run strip /path/to/mounted/share/taskschd.dll and you get "strip:./st9tAIQu: Protocol error" Now to prove a point copy that dll to somewhere on the guest disk, cp /path/to/mounted/share/taskschd.dll /tmp ; strip /tmp and notice that there is no error.

I have absolutely no idea why this only happens with dll files. I am able to strip shared object files without issue. I am also able to strip dll files on windows using mingw from shared folders with no issues. This happens with every dll I have tired. Both the guest and host OS are gentoo.

[dougborg]

I am running into the same problem. I have not yet figured out a fix or a work-around. I am running VirtualBox 4.12 on a Mac OSX 10.8 host with a Debian Squeeze guest.

[larskanis]

I have the same problem when running Ubuntu-12.04 64 Bit VM on Ubuntu-13.10 64 Bit. strip does not work on a shared folder:

$ i686-w64-mingw32-strip zlib1.dll
i686-w64-mingw32-strip:st7VXEcU: Protocol error

Module for shared folders is:

vagrant@precise64:/vagrant/nokogiri$ modinfo vboxsf
filename:       /lib/modules/3.2.0-23-generic/misc/vboxsf.ko
version:        4.2.0 (interface 0x00010004)
license:        GPL
author:         Oracle Corporation
description:    Oracle VM VirtualBox VFS Module for Host File System Access
srcversion:     7C0A7927C2C19F0B88EB55A
depends:        vboxguest
vermagic:       3.2.0-23-generic SMP mod_unload modversions 
parm:           follow_symlinks:Let host resolve symlinks rather than showing them (int)

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.

[jasonmbrown]

I am getting this problem as well, using MXE To CrossCompile, Strip Runs fully it appears. But fails to overwrite the file being stripped. So it exits wih an error and leaves a randomly named file in the shared folder that works fine once renamed.

x86_64-w64-mingw32.static-strip:stqcFQZL: Protocol error

cddadev@ubuntu:~$ modinfo vboxsf
filename:       /lib/modules/4.8.0-27-generic/kernel/ubuntu/vbox/vboxsf/vboxsf.ko
version:        5.1.6_Ubuntu r110634
license:        GPL
author:         Oracle Corporation
description:    Oracle VM VirtualBox VFS Module for Host File System Access
srcversion:     308B21C2D1816AC5CAD8A3A
depends:        vboxguest
intree:         Y
vermagic:       4.8.0-27-generic SMP mod_unload modversions 
parm:           follow_symlinks:Let host resolve symlinks rather than showing them (int)

[kirr]

With VirtualBox 5.1.12 I think I've hit something similar:

​https://lab.nexedi.com/nexedi/wendelin.core/issues/8#note_22095

in short: the following test program when run twice on /media/sf_shared/ gives EPROTO for read syscall:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

void die_errno(const char *msg) {
        perror(msg);
        exit(1);
}

static const char data[1024] = "0123456789...........";
static char data2[1024];

int main() {
        int fd, err;
        off_t off;

        fd = open("testfile", O_RDWR|O_CREAT|O_TRUNC, 0666);
        if (fd == -1) {
                die_errno("open testfile");
        }

        // fstat
        // fstat

        off = lseek(fd, 0, SEEK_SET);
        if (off == -1) {
                die_errno("lseek");
        }

        err = write(fd, data, 645);
        if (err == -1) {
                perror("write");
        }

        off = lseek(fd, 0, SEEK_SET);
        if (off == -1) {
                die_errno("lseek2");
        }

        //err = read(fd, data2, 4096);
        err = read(fd, data2, 645);
        if (err == -1) {
                die_errno("read");
        }

        return 0;
}

kirr@test1:/media/sf_shared$ gcc -Wall -o vboxsf-eproto vboxsf-eproto.c 
kirr@test1:/media/sf_shared$ rm -f testfile 
kirr@test1:/media/sf_shared$ ./vboxsf-eproto    # first time ok - when the file was not there initially
kirr@test1:/media/sf_shared$ ./vboxsf-eproto    # second time -> EPROTO on read
read: Protocol error

[sunlover]

kirr, thanks for the testcase. The fix for the guest additions will be available in the next VirtualBox release.

[Frank Mehnert]

The most recent 5.1 and 5.0 Guest Additions on our test builds page have the fix. Could you confirm?

[Frank Mehnert]

Fix is part of 5.1.14 / 5.0.32. Please upgrade the Guest Additions.