Opened 16 years ago

Closed 5 years ago

#2553 closed defect (invalid)

Shared folders incompatible with gedit

Reported by: AC Owned by:
Component: shared folders Version: VirtualBox 2.0.4
Keywords: gedit, mount Cc:
Guest type: Linux Host type: all

Description (last modified by aeichner)

When mounting a shared folder in a Linux guest (Windows or Linux host), GEdit cannot save changes to any file. This happens regardless of the mount permissions; even files that can be saved with vim/kwrite/etc can't be saved with gedit. Files can be opened and read, but attempting to save results in the generic message "Could not save the file <filename>."

This problem is not new to the 2.X series; I remember bumping into it last year and thought it would be fixed. There are also a number of forum threads referring to this problem (e.g. with no resolution.

This makes using any Ubuntu guest a frustrating experience, as gedit is the default text editor.

Change History (15)

comment:1 by Frank Mehnert, 16 years ago

I cannot reproduce this problem. How did you mount the shared folder to the guest, that is, which option? Note: mount.vboxsf will only allow root (the guest root of course) to mount a shared folder. But if root mounts a shared folder, it will be write-protected for other (guest) users. Use

mount.vboxsf -o uid=<UID>

to change the user ID which owns all files of that directory.

comment:2 by AC, 16 years ago

Yes, I've set the uid and gid; for a shared folder named "shared" the entry in my fstab is:

shared    /home/<username>/sharedfolder    vboxsf    rw,uid=1000,gid=1000,dmode=0755  0  0

although the problem persists regardless of what dmode/fmode combinations I try. In practice the mounted folder is readable/writable by my normal user account (id 1000), and everything works fine except Gedit can't save files. Again, kwrite/vim and other editors save files just fine; there seems to be some odd interaction with gedit.

This is with Windows XP (SP3) host, Ubuntu Hardy guest.

comment:3 by gantengx, 16 years ago

I have the exact same problem. Using VirtualBox 2.10, Windows Vista SP1 host and Ubuntu 8.10 as guest. I can create new file using gedit on shared folder, but i can't rewrite the file. I can only write it to new file.. weird..

However, using other software I can rewrite files (vim, gvim, scribes) with no problem.

comment:4 by Michael Thayer, 15 years ago

Did everyone experiencing this issue have the latest guest additions installed? I seem to recall that we fixed a similar issue in the guest additions a while back.

in reply to:  4 comment:5 by gantengx, 15 years ago

Replying to michael:

Did everyone experiencing this issue have the latest guest additions installed? I seem to recall that we fixed a similar issue in the guest additions a while back.

Really? That's weird... I just updated to virtualbox 2.1.2 and updated the guest additions as well but still facing the problem...

comment:6 by Nazgulled, 15 years ago

I also have this problem and it's really annoying...

Any idea when it's going to be fixed?

comment:7 by Rich McAllister, 15 years ago

I just reproduced this trivially with VirtualBox 2.2.4, Windows XP SP3 host, Ubuntu 9.04 guest. The actual triggering error revealed by strace is that when gedit tries to rename the old file to the backup name it gets ETXTBSY:

rename("/share/CDImages/foo.txt", "/share/CDImages/foo.txt~") = -1 ETXTBSY (Text file busy)

I'm not actually sure this is a VirtualBox bug, since what's happening is the normal annoying Windows rule that one can't rename an open file is being applied.

This did suggest a workaround: in gedit's Edit/Preferences>Editor pane, uncheck the "create a backup copy of files before saving" option; however gedit implements this option by doing the rename anyway and then unlinking the backup copy, so it still fails the same way.

Interestingly the same problem occurred with files on CIFS; samba apparently did something to fix it, but if the CIFS server is Windows it still happens.

comment:8 by Nazgulled, 15 years ago

Any word on this?

comment:9 by Vito Botta, 14 years ago

It doesn't seem to be a Virtualbox bug, as it only happens with Gedit and (some users say) with few other applications.

Here there's a patched version of Gedit that seems to solve this

comment:10 by Josh, 14 years ago

This is not a bug specific to virualbox shared folders. It happens when you use samba/nfs (and likely in other situations as well) to mount folders in linux. it just stems from the fact that not all underlying file systems implement identical interfaces.

I use this script which I call fedit to get around the issue. It creates a simlink under /tmp/ pointing to the file that i pass as an argument. This way the backup file is saved under tmp instead of under the mounted folder structure. It also prevents name collisions under the tmp folder by placing symlinks in a folder structure that mirrors the path of the file they point to.

ps I'm sure the script could stand to be refined, but you get the idea behind how it works.


fullFname=$(readlink -f $1)
fname=$(basename $fullFname)
fpath=$(echo $fullFname | sed s/$fname//)

mkdir -p $tmpdir/$fpath/
ln -s $fullFname $tmpdir/$fpath  2> /dev/null

gedit $tmpdir/$fullFname 2> /dev/null

to use type:


comment:11 by Antonio Scuri, 14 years ago


I have the same problem here. I use win7 host, a NTFS file system shared with the guests, and several guests. In Linux my only problem is with gedit. So I can live with it. But in OpenSolaris the "ar" tool can not generate a library for the same problem. This cause me a lot of workaround.

I know that this is not a VirtualBox bug. But that's a problem that involves VirtualBox. Can you just close a file that it is opened before renaming it when the shared folder is windows based?

BTW I'm using VB 3.2.12 and OpenSolaris 2010.03, but this problem has been there for years and several other versions.

Thanks in Advance, Antonio Scuri

comment:12 by TimSC, 10 years ago

I think the problem is fundamentally with glib and the way it saves to a temporary file, then renames without closing the file. The bug has been recorded as:

comment:13 by aeichner, 8 years ago

Description: modified (diff)
Resolution: obsolete
Status: newclosed

Please reopen if still relevant with a recent VirtualBox release.

comment:14 by frozenspider, 6 years ago

Resolution: obsolete
Status: closedreopened

Even this many years later, this is STILL relevant. Can someone please finally take a look?

comment:15 by Socratis, 5 years ago

Host type: otherall
Resolution: invalid
Status: reopenedclosed

Bumped into this old ticket by accident...


This is not "still relevant" in the VirtualBox ecosystem. Primarily because it's not a VirtualBox issue, there is a bug report with Gnome about this:

Closing this...

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use