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 ftp://ftp-eng.cisco.com/asadhnan/Mini_Driver.zip cap file located at ftp://ftp-eng.cisco.com/asadhnan/PrintDriver_Upload_Error.cap Screen shots with error is located at: ftp://ftp-eng.cisco.com/asadhnan/ScreenNote.doc 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 only file 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. Jeremy.
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. Jeremy.