rm: file: Text file busy // Freebsd 12.1-RELEASE-p10 Virtualbox Guest cannot delete files in shared folder

teksimian

New Member


Messages: 9

I'm running a Freebsd 12.1 in virtualbox on a win10 host. Guest additions, kmod installed.

Followed the handbook; https://www.freebsd.org/doc/handbook/virtualization-guest-virtualbox.html

Mounted a shared folder.
Files pre-existing in that folder can be deleted. New files can be created.
Newly created files cannot be deleted. rm returns;

rm: mytestfile.txt: Text file busy


user@devbox /media> sudo mount_vboxvfs -w DEVBOX /media/devbox/
VBOXVFS[1]: sfprov_mount: Enter
VBOXVFS[1]: sfprov_mount: path: [DEVBOX]
sfprov_mount(DEVBOX): error=0 rc=0
user@devbox /media> sudo umount /media/devbox
user@devbox /media> sudo mount_vboxvfs -w DEVBOX /media/devbox/
VBOXVFS[1]: sfprov_mount: Enter
VBOXVFS[1]: sfprov_mount: path: [DEVBOX]
sfprov_mount(DEVBOX): error=0 rc=0
user@devbox /media> cd devbox/
user@devbox /m/devbox> ls
blog mytestfile.txt vendor
user@devbox /m/devbox> rm mytestfile.txt
user@devbox /m/devbox> touch mytestfile.txt
user@devbox /m/devbox> rm mytestfile.txt
rm: mytestfile.txt: Text file busy
user@devbox /m/devbox [1]>


Also tried to delete as root, same results.
I can also try to mount it with user uid, gid, same results.
sudo mount -t vboxvfs -o rw,gid=1001,uid=1001 DEVBOX /media/devbox/

I also cannot delete it on the windows host. windows tells me the file is open in virtualbox and cannot be deleted.
1600565984306.png


user@devbox /m/devbox> uname -a
FreeBSD devbox 12.1-RELEASE-p10 FreeBSD 12.1-RELEASE-p10 GENERIC amd64
user@devbox /m/devbox> pkg info |grep virtua
virtualbox-ose-additions-5.2.44 VirtualBox additions for FreeBSD guests
virtualbox-ose-kmod-5.2.44 VirtualBox kernel module for FreeBSD
user@devbox /m/devbox> kldstat
Id Refs Address Size Name
1 9 0xffffffff80200000 2448f20 kernel
2 2 0xffffffff82819000 2eb53 vboxguest.ko
3 1 0xffffffff82848000 2668 intpm.ko
4 1 0xffffffff8284b000 b50 smbus.ko
5 1 0xffffffff8284c000 1fb33 vboxvfs.ko
user@devbox /m/devbox> mount
/dev/gpt/rootfs on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
SHAREDVM on /media/SHAREDVM (vboxvfs, asynchronous, local)
DEVBOX on /media/devbox (vboxvfs, local)


dmesg -a
...
vboxguest0 port 0xd040-0xd05f mem 0xf1400000-0xf17fffff,0xf1800000-0xf1803fff irq 20 at device 4.0 on pci0
vboxguest: loaded successfully
...
Starting vboxservice.
VBoxService 5.2.44 r139111 (verbosity: 0) freebsd.amd64 (Sep 6 2020 08:56:05) release log
00:00:00.001229 main Log opened 2020-09-19T21:30:46.747355000Z
00:00:00.001300 main OS Product: FreeBSD
00:00:00.001319 main OS Release: 12.1-RELEASE-p10
00:00:00.001337 main OS Version: FreeBSD 12.1-RELEASE-p10 GENERIC
00:00:00.001351 main Executable: /usr/local/sbin/VBoxService
00:00:00.001355 main Process ID: 633
00:00:00.001359 main Package type: BSD_64BITS_GENERIC (OSE)
00:00:00.016708 main 5.2.44 r139111 started. Verbose level = 0
...
 

olli@

Daemon
Developer

Reaction score: 1,255
Messages: 1,140

Maybe this is related to VirtualBox Bug #19086. Apparently these kind of problems exist since VB 4.x about 10 years ago, and it’s still not reliably fixed in 6.x. You can find many similar problem reports all over the internet.

It would be interesting to see if rm -f makes a difference (I guess it doesn’t). You could also check if renaming or moving the file with mv works, or whether you can modify it, for example with echo >> mytestfile.txt.

By the way, the error message “text file busy” is misleading. In this context, “text file” does not refer to a file that contains textual data (like ASCII text). Historically, executable binary code was called text code, and code segments within ELF files are called text segments. The error code ETXTBSY (text file busy) is used on certain file systems when you try to modify a binary file that is currently being executed, and it’s locked by the kernel. However, I have no idea why it happens in the case described above. Apparently, for some reason VirtualBox locks the file and prevents it from being removed.
 

vigole

Daemon

Reaction score: 1,476
Messages: 1,285

  1. Download procexp64.exe (*) from Sysinternals.
  2. Run procexp64.exe on Windows guest.
  3. Try to delete mytestfile.txt in the windows.
  4. Search in the procexp64.exe for mytestfile.txt name.
  5. Take a note of the name of process/processes, which binds to mytestfile.txt in windows.
  6. If it's possible show us more information taken form Lower Pane window.
(*) If your guest is 32bit, use procexp.exe instead of procexp64.exe
 
OP
T

teksimian

New Member


Messages: 9

root@devbox:/media # mount_vboxvfs -w DEVBOX /media/devbox/
root@devbox:/media # ls devbox/
blog mytestfile.txt vendor
root@devbox:/media # cd devbox/
root@devbox:/media/devbox # rm mytestfile.txt
root@devbox:/media/devbox # touch mytestfile.txt
root@devbox:/media/devbox # rm mytestfile.txt
rm: mytestfile.txt: Text file busy
root@devbox:/media/devbox # cat mytestfile.txt
root@devbox:/media/devbox # echo 123 > mytestfile.txt
root@devbox:/media/devbox # cat mytestfile.txt
123
root@devbox:/media/devbox # rm mytestfile.txt
rm: mytestfile.txt: Text file busy
root@devbox:/media/devbox # echo 456 > mytestfile.txt
root@devbox:/media/devbox # cat mytestfile.txt
456
root@devbox:/media/devbox # rm -f mytestfile.txt
rm: mytestfile.txt: Text file busy
root@devbox:/media/devbox #
root@devbox:/media/devbox # mv mytestfile.txt mytestfile2.txt
mv: rename mytestfile.txt to mytestfile2.txt: Text file busy


interesting, I can actually overwrite the file, but not move it or remove it.
 
OP
T

teksimian

New Member


Messages: 9

  1. Download procexp64.exe (*) from Sysinternals.
  2. Run procexp64.exe on Windows guest.
  3. Try to delete mytestfile.txt in the windows.
  4. Search in the procexp64.exe for mytestfile.txt name.
  5. Take a note of the name of process/processes, which binds to mytestfile.txt in windows.
  6. If it's possible show us more information taken form Lower Pane window.
(*) If your guest is 32bit, use procexp.exe instead of procexp64.exe
1601349885229.png

1601350014500.png

1601350042905.png

1601350073647.png
 
Top