Operation Not Permitted Copying Files from Linux Guest to Windows Host via Shared Folder => Fixed in SVN

[William Ruppel]

[wruppel@wruppel-dev occam]$ cp /smb/slc12ctr.us.oracle.com:Sooners/SprintReviews/R39/Sprint03/* /media/sf_E_DRIVE/Temp/Sooners.mp4
cp: preserving times for ‘/media/sf_E_DRIVE/Temp/Sooners.mp4’: Operation not permitted                                                                                                                                                                                                                                                                                                                                    

I've changed nothing in the machine settings, and this worked fine in 6.0.4. Also, I see there were changes in 6.0.6 related to shared folders.

So, I think something has regressed.

Thanks.

[ETiktin]

I've encountered the exact problem. After upgrading from 6.0.4 to 6.0.6 (including guest additions), copying or moving files to a shared folder print the error message: "preserving times for ‘<SOME_PATH>’: Operation not permitted".

Note that the file is actually copied/moved to the shared folder, it's just the timestamps are not preserved (i.e. create a file, after 2 minutes copy it to the shared folder, then compare the timestamps of the 2 files and you will see they are different).

My host is Windows 10 and guest is Linux Mint 19.1.

[Socratis]

In order for *any* ticket to have gravitas, it needs a couple of things:

1. To be reproducible, i.e. have a step-by-step "How to reproduce", even better if it's accompanied by a "It fails in such and such a case, but it works in this and that case".

2. To follow the instructions when you when you filed the bug:

   Attach a (full) log file ("Machine" menu/"Show Log" in the main VirtualBox Manager window) straight away to save time for you and for us. The log file contains a lot of useful information about both the host and the guest systems as well as information about what happened during a particular machine run. Please do not cut and paste it.

[William Ruppel]

Log file.

[William Ruppel]

This issue is reproducible every time, just by copying a file as I showed above. There is nothing else required.

[Brewsters]

Same problem using Centos 7.6 guest with Win10 host. 100% reproducible. The problem started after upgrading from 6.0.4 to 6.0.6 (both VirtualBox and Guest Additions)

$ cp -p test-file.war /media/sf_VMShared/test-file.war
cp: preserving times for ‘/media/sf_VMShared/test-file.war’: Operation not permitted
$ ls -l test-file.war /media/sf_VMShared/test-file.war
-rwxrwx--- 1 root     vboxsf   1428026 Apr 24 10:16 /media/sf_VMShared/test-file.war
-rw-r--r-- 1 brewsters brewsters 1428026 Apr 23 13:10 test-file.war
$ uname -a
Linux ops_test 3.10.0-957.10.1.el7.x86_64 #1 SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[BrainomixSimon]

We are having the same problem here. I am running a Ubuntu 18.04 guest on a Windows 10 host, but my colleague running a similar guest on a MacOS host has had the same issue.

Boiled down to a trivial repro case, we have this behaviour in 6.0.4: (/media/sf_brainomix is a read/write shared folder)

brainomix@devbox:~$ touch somefile
brainomix@devbox:~$ ll somefile
-rw-r--r-- 1 brainomix vboxsf 0 Apr 26 16:51 somefile
brainomix@devbox:~$ cp -p somefile /media/sf_brainomix/
brainomix@devbox:~$ ll /media/sf_brainomix/somefile 
-rwxrwx--- 1 root vboxsf 0 Apr 26 16:51 /media/sf_brainomix/somefile*

The file is copied, the time is preserved, the mode and ownership is changed to match the shared folder defaults. Great.

On 6.0.6 (with the 6.0.6 guest additions installed), we get this:

brainomix@devbox:~$ touch somefile
brainomix@devbox:~$ ll somefile
-rw-r--r-- 1 brainomix vboxsf 0 Apr 26 16:41 somefile
brainomix@devbox:~$ cp -p somefile /media/sf_brainomix
cp: preserving times for '/media/sf_brainomix/somefile': Operation not permitted
brainomix@devbox:~$ ll /media/sf_brainomix/somefile
ls: cannot access '/media/sf_brainomix/somefile': No such file or directory

According to the cp man page, -p is equivalent to --preserve=mode,ownership,times, so let's see what works and what doesn't:

brainomix@devbox:~$ cp --preserve=times somefile /media/sf_brainomix
cp: preserving times for '/media/sf_brainomix/somefile': Operation not permitted
brainomix@devbox:~$ ll /media/sf_brainomix/somefile
ls: cannot access '/media/sf_brainomix/somefile': No such file or directory

No surprise, "times" fails. I'm lazy, so let's try both of the others...

brainomix@devbox:~$ cp --preserve=mode,ownership somefile /media/sf_brainomix
brainomix@devbox:~$ ll /media/sf_brainomix/somefile
-rwxrwx--- 1 root vboxsf 0 Apr 26 16:42 /media/sf_brainomix/somefile*

That works, but the time is different (as expected, given the options).

Edit: We also saw similar errors when copies were made by Python scripts, when tar files were extracted into the shared folder and when rsync -a was copying files into it.

[zardoz]

It's actually worse than not just setting times. Rsync actually fails to transfer the files.

Example:

rsync -av zardoz@remote:~/.ssh .
receiving incremental file list
rsync: failed to set times on "/media/sf_VirtualBox_Shared/Test/.ssh": Operation not permitted (1)
.ssh/
rsync: mkstemp "/media/sf_VirtualBox_Shared/Test/.ssh/.authorized_keys.8ORm8T" failed: Operation not permitted (1)
rsync: mkstemp "/media/sf_VirtualBox_Shared/Test/.ssh/.id_dsa.qYF4ga" failed: Operation not permitted (1)
rsync: mkstemp "/media/sf_VirtualBox_Shared/Test/.ssh/.id_dsa.pub.jLQqqq" failed: Operation not permitted (1)
rsync: mkstemp "/media/sf_VirtualBox_Shared/Test/.ssh/.id_rsa.TUChBG" failed: Operation not permitted (1)
rsync: mkstemp "/media/sf_VirtualBox_Shared/Test/.ssh/.id_rsa.pub.SnczPW" failed: Operation not permitted (1)
rsync: mkstemp "/media/sf_VirtualBox_Shared/Test/.ssh/.known_hosts.ll1aad" failed: Operation not permitted (1)

sent 129 bytes  received 6,390 bytes  4,346.00 bytes/sec
total size is 5,934  speedup is 0.91
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1659) [generator=3.1.3]

The copy completely fails to populate the destination folder, which IS created.

This is only since 6.0.6 was installed. Host: Windows 7 Pro - Guest: Fedora 29 x86_64

[zardoz]

The problem persists with 6.0.8 :-(

[pilchkinstein]

Some of this works in 6.0.8 But "Operation not permitted" for git checkouts:

$ terraform init Initializing modules...

• module.logstash...... Getting source "git::​ssh://git@bitbucket.org/<GIT_PATH>"

Error downloading modules: Error loading modules: error downloading '​ssh://git@bitbucket.org/<GIT_PATH>': /usr/bin/git exited with 128: Cloning into '.terraform/modules/95048d55dc5e3d68ef6e88be677623af'... error: chmod on .terraform/modules/95048d55dc5e3d68ef6e88be677623af/.git/config.lock failed: Operation not permitted fatal: could not set 'core.filemode' to 'false'

[Reiner Brodbeck]

Due to other bugs related to shared folders I was not able to use VirtualBox v6.0.x up to now. Using the current test build 6.0.9-130868 and Guest Additions 6.0.9-130824, these problems are solved, and now I am also experiencing problems in shared folders:

• The "preserving times" problem already mentioned
• Trying to delete a complete directory structure with "rm -r dir" results in only deleting the files in that directory, but the directory itself is not deleted, error message "rm: cannot remove `dir': Text file busy"
• And there some more strange behaviour that I could not yet identify exactly

My guest is CentOS 6.10, kernel 2.6.32-504.el6.x86_64

[laurio]

I'm having the same issue. For example cloning a git repository fails to a shared folder when using 6.0.8, just to mention one of the problems I faced. After downgrading to 6.0.4 the issues don't exist. Using Windows 10 host and Ubuntu 18.04 LTS guest.

This is a showstoppper-level issue for me, could you please fix this to next version, thank you.

[Socratis]

Replying to laurio:

This is a showstoppper-level issue for me

You can always use true network shares, SMB/CIFS or NFS or something else that works in the mean time. Or downgrade...

[bird]

Should be fixed by r78860.

[Socratis]

Replying to bird:

Should be fixed by r78860.

Do you happen to know what public Testbuilds this would correspond to?

[Reiner Brodbeck]

With guest additions 6.0.9-131148 the"preserving times" problem is fixed, but "rm -r" command still has "Text file busy" error message.

[zardoz]

The latest Guest Additions 6.0.9-131183 Seems to have fixed the rsync problem as well.

[John Bokma]

The following git session results in

error: insufficient permission for adding an object to repository database .git/objects

mkdir hello && cd $_
git init
touch hello.txt
git add hello.txt

I guess this is related.

Edit: see also ​http://johnbokma.com/blog/2019/06/16/git-permission-issue-with-virtualbox-shared-folders.html

[Daniel Pielmeier]

I tested VirtualBox 6.0.10 today. The directory removal problem is still present. I already mentioned this in bug #18345 but as this issue seems more suitable I add the information here again.

In my example the user running VirtualBox has full control on the shared folder of the host (Windows 10 Enterprise, 1803). The user within the Linux guest (Ubuntu 18.04.02 LTS) is in the is in the vboxfs group. The shared folder is mounted with the following options: rw,nodev,relatime,iocharset=utf8,uid=0,gid=999,dmode=0770,fmode=0770,tag=VBoxAutomounter

On the guest within a shell the user is able to create and and delete files and directories:

~/shared$ mkdir test
~/shared$ rmdir test
~/shared$ touch file
~/shared$ rm file

However under some conditions directory removal fails.

Within the guest there is OpenFOAM running. One application namely ​foamListTimes which should remove files and directories fails to remove directories. I think it executes the rmdir function from ​POSIX.C

The output I get from foamListTimes is:

bool Foam::rm(const Foam::fileName&) : Removing : "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water/U.gz"
bool Foam::rm(const Foam::fileName&) : Removing : "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water"
--> FOAM Warning : 
    From function bool Foam::rmDir(const Foam::fileName&)
    in file POSIX.C at line 1103
    failed to remove directory "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water"
--> FOAM Warning : 
    From function bool Foam::rmDir(const Foam::fileName&)
    in file POSIX.C at line 1073
    failed to remove directory "fluid_water" while removing directory "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4"

So it successfully removes the files within the directory "U.gz" but then fails to remove the directory "fluid_water" itself.

[coyote]

I'm a dev and I'm using vbox for local development. Pointed Apache's webroot to the shared folder so all files are contained within Windows file system.

Composer install fails to pull dependencies because it's unable to move/remove folders. As a workaround I need to relocate project files project to the guest and it's pretty inconvenient way to work.

Can this issue be prioritize and resolved rather quickly?

[Socratis]

Replying to coyote:

Can this issue be prioritize and resolved rather quickly?

Not unless you're a paying customer, which I suspect you're not, because you'd have already talked to your customer representative. I know that everyone's bug is "the" most important one, but the developers know better their timetables... ;)

Composer install fails to pull dependencies because it's unable to move/remove folders

Interesting that you mention "Composer". There's another ticket (#18776, see the comments) that just got opened/semi-resolved that was dealing with "Composer". Maybe you're seeing the same issue?

[Reiner Brodbeck]

I tested version 6.0.10 today. The "rm -r dir" problem mentioned in comment 9 still exists.

[Daniel Pielmeier]

The problem is still reproducible with VirtualBox 6.0.14.

[Frank Batschulat (Oracle)]

Replying to Daniel Pielmeier:

The problem is still reproducible with VirtualBox 6.0.14.

OS version of the Host, OS version of the guest VM please?

[Frank Batschulat (Oracle)]

The issue reported in this bug has been fixed and I verified this again with

Host: Windows 10 build 1903/Virtualbox 6.0.14/Guest: Ubuntu 18.04.03

Host: Windows 10 build 1809/Virtualbox 6.0.12/Guest: Ubuntu 18.04.03

Whatever problems you might have, it is not this bug.

You may run into the following bug:

Ticket #18776 (accepted defect) Vagrant shared folders unable to install Package Management Plugins (Composer, PHP)
https://www.virtualbox.org/ticket/18776

Or a completely different issue for which a detailed new bug should be filed.

Please do not clutter this resolved bug any further with unrelated issues and annotations.