Opened 6 years ago
Closed 5 years ago
#18569 closed defect (fixed)
Operation Not Permitted Copying Files from Linux Guest to Windows Host via Shared Folder => Fixed in SVN
Reported by: | William Ruppel | Owned by: | Frank Batschulat (Oracle) |
---|---|---|---|
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 (1)
Change History (27)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
In order for *any* ticket to have gravitas, it needs a couple of things:
- 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".
- 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.
comment:3 by , 6 years ago
This issue is reproducible every time, just by copying a file as I showed above. There is nothing else required.
comment:4 by , 6 years ago
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 by , 6 years ago
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.
comment:6 by , 5 years ago
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:8 by , 5 years ago
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'
comment:9 by , 5 years ago
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
follow-up: 11 comment:10 by , 5 years ago
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 by , 5 years ago
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...
follow-up: 13 comment:12 by , 5 years ago
Summary: | Operation Not Permitted Copying Files from Linux Guest to Windows Host via Shared Folder → Operation Not Permitted Copying Files from Linux Guest to Windows Host via Shared Folder => Fixed in SVN |
---|
Should be fixed by r78860.
comment:13 by , 5 years ago
Replying to bird:
Should be fixed by r78860.
Do you happen to know what public Testbuilds this would correspond to?
comment:14 by , 5 years ago
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 by , 5 years ago
The latest Guest Additions 6.0.9-131183 Seems to have fixed the rsync problem as well.
comment:16 by , 5 years ago
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
comment:17 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:18 by , 5 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
follow-up: 20 comment:19 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
I tested version 6.0.10 today. The "rm -r dir" problem mentioned in comment 9 still exists.
comment:23 by , 5 years ago
Owner: | set to |
---|---|
Status: | reopened → assigned |
comment:24 by , 5 years ago
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?
comment:25 by , 5 years ago
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.
comment:26 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.