I use NFS to edit files on servers. When these files are scripts with shebang lines, and I execute them, I get the "text file busy" error for about 5 seconds after I save each time.

The same problem is reproducible if a file is opened in vi (on 4.19 kernel), as follows:

chmod +x test.sh
vi test.sh
# Ctrl-Z to suspend vi
# text file busy: ./test.sh

On 5.7 kernel the above vi example doesn't produce the error but NFS write from 5.7 to 5.7 system still yields the "text file busy" error for 5 seconds after each save.

Per https://stackoverflow.com/questions/16764946/what-generates-the-text-file-busy-message-in-unix the error can be worked around by explicitly invoking the binary that runs the script:

bash test.sh

I believe I can then write a script, call it e, that will open the path given by the argument, see if the file begins with the shebang, if so parse the shebang line and invoke the binary in the shebang manually:

e ./test.sh

But, this begs the question: what am I paying my operating system for?

How can I configure Linux to execute files open for writing?

I grepped the 5.7 kernel source for ETXTBUSY and it produced no hits.

Alternatively, as a less universal workaround, how can I make it so that writes over NFS immediately close the file being written instead of keeping it open for ~5 seconds?


The issue with vi (nvi, to be more precise), per a comment, is this one which is fixed in 1.81.6-16 on Debian (my 4.19 system has 1.81.6-15 and 5.7 system has 1.81.6-16). I would still like to figure out how to make NFS saves not produce the text file busy error.

Second edit:

/etc/exports on the server:


Mounted with -o soft,intr:

serene:/home/w on /mnt/speed type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=,local_lock=none,addr=

Server packages (Devuan testing):

serene% dpkg -l|grep nfs
ii  libnfsidmap2:amd64                   0.25-5.1                            amd64        NFS idmapping library
ii  nfs-common                           1:1.3.4-4                           amd64        NFS support files common to client and server
ii  nfs-kernel-server                    1:1.3.4-4                           amd64        support for NFS kernel server

Client packages on the working client where I cannot currently reproduce the issue (Devuan testing):

averagest% dpkg -l|grep nfs
ii  libnfsidmap2:amd64                   0.25-5.1                           amd64        NFS idmapping library
ii  nfs-common                           1:1.3.4-4                          amd64        NFS support files common to client and server
  • Yes I use nvi, thanks for that link. Maybe there is no kernel behavior difference between 4.19 and 5.7 then. I run into the vi issue when editing files on servers, good to know updating nvi would fix it. I would still like to figure out how to not run into this issue when saving files over NFS.
    – D. SM
    Commented Aug 29, 2020 at 0:33
  • I'd expect a search for EBUSY to be more useful. ETXTBUSY is not a defined error. Commented Sep 5, 2020 at 2:09
  • 1
    @StephenHarris Actually, the OP should've searched for ETXTBSY (without U), which is very well defined.
    – user313992
    Commented Sep 5, 2020 at 13:08
  • @D.SM Hi, what is your nfs mount options in /etc/exports ?
    – binarysta
    Commented Sep 8, 2020 at 9:33
  • NFS version 3 or 4? What OS does the NFS server run? Commented Sep 8, 2020 at 22:16

1 Answer 1


I can't comment yet, but can you give us more specifics on your environment?

I am unable to reproduce the behavior you are seeing. For example, I have an NFS filesystem mounted on /test. If I run the following command, it returns immediately, no 5s delay at all:

$ cd /test
$ vi xx; chmod 755 xx; ./xx
Tue Sep  8 17:45:17 EDT 2020

The contents I put into xx are:


In addition, if I "vi xx" and CTRL-Z to suspend, there is no delay, nor is there any error:

$ vi xx
[1] + Stopped                  vi xx
$ ./xx
Tue Sep  8 17:51:01 EDT 2020

I'm testing on: CentOS Linux release 7.7.1908. I wouldn't expect NFS to behave differently between linux's, but you never can be sure.

If you use vim instead of nvi, does the behavior change?

What does "mount | grep nfsmountpoint" show?

  • Thanks for the response. I am testing again from Devuan testing to Devuan testing and NFS saves seem to work fine. I had the issue going from Devuan stable to Devuan testing. I'll test more to narrow this down.
    – D. SM
    Commented Sep 9, 2020 at 0:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .