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



## teksimian (Sep 20, 2020)

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.





`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@ (Sep 20, 2020)

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.


----------



## a6h (Sep 20, 2020)

Download procexp64.exe (*) from _Sysinternals_.
Run procexp64.exe on Windows guest.
Try to delete mytestfile.txt in the windows.
Search in the procexp64.exe for mytestfile.txt name.
Take a note of the name of process/processes, which binds to mytestfile.txt in windows.
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


----------



## teksimian (Sep 29, 2020)

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


----------



## teksimian (Sep 29, 2020)

vigole said:


> Download procexp64.exe (*) from _Sysinternals_.
> Run procexp64.exe on Windows guest.
> Try to delete mytestfile.txt in the windows.
> Search in the procexp64.exe for mytestfile.txt name.
> ...


----------



## sremick (Monday at 11:19 PM)

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?


----------



## Vull (Tuesday at 1:48 AM)

Try:
	
	



```
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:
	
	



```
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]


----------



## K5KGT (Tuesday at 2:07 AM)

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.


----------



## Vull (Tuesday at 2:22 AM)

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


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: 
	
	



```
PS1="$ " ; export PS1
$
```
... then you can use pwd() to see the full pathname:
	
	



```
$ pwd
/media/devbox
$
```


----------



## sremick (Tuesday at 3:58 AM)

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.




```
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
```


----------

