We investigated a case where Codex in VS Code failed to apply patches when the project was opened from a Samba/SMB network share. The client showed an error similar to:
Failed to read file to update index.php: Access denied (os error 5)
After auditing the Samba share, we found that the target file itself was readable and openable through SMB. In the server audit logs, index.php was opened successfully multiple times, which suggests the failure was not a simple file-permission denial on the Samba side.
We also tested common Samba-side mitigations, including share configuration fixes, permissions cleanup, and lock/oplock changes. None of those made Codex patching work reliably over the SMB share.
Based on the logs, the practical conclusion was:
-
normal access to the project over Samba worked;
-
the target file
index.phpcould be opened successfully; -
Codex patch application over that SMB-share workflow did not work reliably.
In other words, this appears to be a client/workspace-level limitation or bug in the patching flow, not a straightforward Samba read/write permission problem on the target PHP file.
Environment
-
VS Code with Codex
-
Project opened from a Samba/SMB network share
-
Windows client
-
Linux server running Samba
Expected behavior
Codex should be able to apply patches to files in a project opened from a Samba/SMB share when the target file is readable and writable.
Actual behavior
Codex reports an access-denied style error during patch application, even though Samba audit logs show the target file can be opened successfully.
Additional note
The error message shown by the client appears misleading or too generic for this scenario, because the Samba logs do not show a direct access denial on the target file itself.