VirtualBox

Ticket #18569 (reopened defect)

Opened 4 months ago

Last modified 38 hours ago

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

Reported by: William Ruppel Owned by:
Component: shared folders Version: VirtualBox 6.0.6
Keywords: Cc:
Guest type: Linux Host type: Windows

Description

[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.

Attachments

Oracle Dev-2019-04-22-19-56-50.log Download (95.3 KB) - added by William Ruppel 4 months ago.
Log file.

Change History

comment:1 Changed 4 months ago by 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.

comment:2 Changed 4 months ago by 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".
  1. 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.

Changed 4 months ago by William Ruppel

Log file.

comment:3 Changed 4 months ago by William Ruppel

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

comment:4 Changed 4 months ago by 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

comment:5 Changed 4 months ago by 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.

Last edited 4 months ago by BrainomixSimon (previous) (diff)

comment:6 Changed 3 months ago by 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

comment:7 Changed 3 months ago by zardoz

The problem persists with 6.0.8 :-(

comment:8 Changed 3 months ago by pilchkinstein

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

$ 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'
Last edited 3 months ago by pilchkinstein (previous) (diff)

comment:9 Changed 3 months ago by ReinerB

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

comment:10 follow-up: ↓ 11 Changed 3 months ago by 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.

comment:11 in reply to: ↑ 10 Changed 3 months ago by 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...

comment:12 follow-up: ↓ 13 Changed 3 months ago by bird

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

Should be fixed by r78860.

comment:13 in reply to: ↑ 12 Changed 3 months ago by socratis

Replying to bird:

Should be fixed by r78860.


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

comment:14 Changed 3 months ago by ReinerB

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

comment:15 Changed 3 months ago by zardoz

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

comment:16 Changed 2 months ago by 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

Last edited 2 months ago by John Bokma (previous) (diff)

comment:17 Changed 5 weeks ago by michael

  • Status changed from new to closed
  • Resolution set to fixed

comment:18 Changed 5 weeks ago by Daniel Pielmeier

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:19 follow-up: ↓ 20 Changed 4 weeks ago by 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?

comment:20 in reply to: ↑ 19 Changed 4 weeks ago by 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?

comment:21 Changed 38 hours ago by ReinerB

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

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use