linux - "/bin/bash: bad interpreter: Text file busy" even though the file editor closed the file

I have a script on Linux that I edit under Windows (through Samba), that starts with the shebang line #!/bin/bash. Even though:

• I finish editing, save, and close the file in the editor


• make sure the file is not opened anywhere else


• make sure the file is saved with Unix line ending


• cat the file under Linux and make sure the edit is present


• stat the file under Linux and make sure it has the timestamp after editing

I still get the error /bin/bash: bad interpreter: Text file busy when I try to execute it, for a while (about a minute or two). Why??

NOTE: the file is not cached on the client. The file is visible on the server by cat. It is also possible to run /bin/bash on it. It is only when the shebang line is used, that is, when the file itself is executed, that the above error happens.

Answer

Samba supports something called opportunistic locking.

When a client wants to read a file and nobody is writing the file, Samba will give the client a read oplock. This allows the client to cache data without having to read it over and over from the server. If another client wants to write to the file, Samba will issue a "break oplock" request to the client with the oplock, so it knows it can't cache anymore.

Similarly, when a client wants to write a file and nobody else is accessing the file, Samba will give the client a write oplock. This allows it to buffer writes, cache reads and assume it can read its own writes back without having to bother the server. If another client wants to read from, or write to, the file, Samba will issue a "break oplock" request to the client with the oplock, forcing it to flush all its buffered writes and stop the buffering and caching.

What's happening is the Windows machine holds a write oplock. And since you're accessing the file from the host (rather than through Samba), Samba has no chance to ask the client to break the oplock. As a result, the server has no way to know whether the contents of the file are usable or whether the real contents are still known only to the client. Until the write oplock is broken, the file cannot be executed.

You can, if you wish, configure Samba not to use oplocks for that share, file, extension, or whatever makes sense. There will be a performance loss as caching and buffering will be reduced.