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

T

teksimian

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
...
 
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.
 
  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
 
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.
 
vigole said:
  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
Click to expand...
1601349885229.png

1601350014500.png

1601350042905.png

1601350073647.png
 
First of all: I know this thread is old, however it's the exact same thing I'm experiencing, so it's still an issue.
Also see: https://forums.freebsd.org/threads/10-2-vbox-shared-folders-mounting.55091/

I'm on FreeBSD 13.1-RELEASE-p5, running in a VM on VirtualBox 7.0.4 on a Windows 11 host. I have the Dropbox shared folder working for the most part, but it's basically read-only due to this issue (FreeBSD guest VM can create new files, but then can't modify them).

Did anyone ever find a solution to this?
 
Try:
Code: 
user@devbox /media> cd devbox/
user@devbox /m/devbox> ls
blog           mytestfile.txt vendor
user@devbox /m/devbox>cd /
user@devbox />rm /m/devbox/mytestfile.txt
user@devbox />umount />sudo umount /media/devbox
... or, maybe:
Code: 
user@devbox />rm /media/devbox/mytestfile.txt
[Edited to add:]
1. The file will be "busy" for as long as /media/devbox remains your "present working directory (pwd)."
2. The file might not get "flushed," or written to your media drive, until you close the file with umount().
[/Edited to add]
 
Vull , sorry to nit-pick, but your shell prompt makes following "what to type" difficult unless the reader realizes what they're looking at. However, you're right, possibly trying the full pathname will give info.

sremick , Does FreeBSD somehow think the file is still open by a process? maybe try fstat <filename> (in your FreeBSD VM) to see if something's holding it open.
 
K5KGT said:
Vull , sorry to nit-pick, but your shell prompt makes following "what to type" difficult unless the reader realizes what they're looking at. However, you're right, possibly trying the full pathname will give info.
<snip> ...
Click to expand...
K5KGT: I followed the shell user dialog style from post #1
Other shells might use different dialog styles. If seeing the pathname in the shell prompt makes following "what to type" difficult for you, try setting your PS1 shell prompt environment variable to a simple prefix character followed by a space, for example:
Code: 
PS1="$ " ; export PS1
$
... then you can use pwd() to see the full pathname:
Code: 
$ pwd
/media/devbox
$
 
K5KGT said:
sremick , Does FreeBSD somehow think the file is still open by a process? maybe try fstat <filename> (in your FreeBSD VM) to see if something's holding it open.
Click to expand...

Code: 
root@FreeBSD-VM:/home/scott/Dropbox # ls -l test
-rwxrwxrwx  1 root  wheel  0 Jan  9 18:09 test
root@FreeBSD-VM:/home/scott/Dropbox # fstat test 
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME
root@FreeBSD-VM:/home/scott/Dropbox # rm test
rm: test: Text file busy
 
You must log in or register to reply here.
Back
Top