The Samba-Bugzilla – Bug 3035
write access requested on read only file
Last modified: 2006-01-15 22:47:26 UTC
Tried to upload manufacturer drivers to the print server.
During the upload, the administrator got an warning that this is not digitally
signed driver by Microsoft, the user then clicks ok to acknowledge the warning
and when he proceeds he got an Access denied error.
1. The workaround was to use generic driver from MSFT, but the customer looses
important advanced features, such as two-sides printing.
2. Same driver on native print server works fine.
Driver located at
cap file located at
Screen shots with error is located at:
Printer model is Kyocera Mita FS-C5610N
We are using CUPS version 1.1.17 to create a printer on the print server.
The 'access denied' has nothing to do with the digitial
signature of driver. And the trace doesn't fully decode
the dcerpc traffic.
I'll try reprodicing the failure.
ok. Quick workaround. Just unset the read-only attribute
on the ppd file prior to the driver installation. That works
fine. I tested against 3.0.20.
Jeremy, We might have a bug here in the file serving code.
This is the error I see in the log file when the read only bit is
set on the client's local filesystem.
get_ea_dos_attribute: W32X86/SET426.tmp attrstr = 0x21
get_ea_dos_attribute returning (0x21)ra
open_file_ntcreate: fname=W32X86/SET426.tmp, after mapping access_mask=0x20196
open_file_ntcreate: write access requested for file W32X86/SET426.tmp on read
set_bad_path_error: err = 13 bad_path = 0
unix_error_packet: error string = Permission denied
error packet at smbd/trans2.c(2593) cmd=162 (SMBntcreateX) NT_STATUS_ACCESS_DENIED
But I've testing uploading the driver against Windows 2000
and Windows 2003 with the read-only bit set and there is no failure.
So it appears we have some semantics wrong here.
*** Bug 2813 has been marked as a duplicate of this bug. ***
It's possible this got fixed with the change I added for Bug #3088.
Created attachment 1686 [details]
Proposed patch: Do not check read-only dosmode at open
On Windows share, a file with read-only dosmode can be opened with
DELETE_ACCESS. But on Samba share (delete readonly = no), it
failed by NT_STATUS_CANNOT_DELETE error.
This samba's-semantic occurs a problem that user can not
rename a file with read-only dosmode on Samba share
from Windows command prompt (i.e. cmd.exe, but can rename
from Windwos Explorer).
Makes perfect sense - thanks ! Applied.