Short description of likely problem: It looks like it is a bug in Samba because what really happens is that "fd_open" tries to open the file with O_RDWR (with flags=0x2) and gets the error "Permission denied" because the user doesn't have the write permission to the file. However smbd/open_file.c misrepresents the error as "No such file or directory" if the parent directory name contains non-ASCIIs? Long-winding description: A path like this: \\samba\ä\a.xls cannot be found by Excel unless the user (or his group) has the write privilege on the file. (The funny looking directory name is a German "a" with a lazy colon on top of it, ASCII code 0xe4.) A symbolic link "ae->ä" solves the problem: \\samba\ae\a.xls pointing to the same file through an ASCII symbolic link is OK but unpracticable. The problem doesn't show up if the user (or his group) has write-access to the file. It looked like the problem was in the following global parameter of my samba 2.2.8a: character set = ISO8859-1 If it is set as shown the paths with special German characters appear as expected both on an SMB client and on the Linux box (SuSE 8.1 with kernel 2.4.20-4GB) but then we have the said problem with Excel (and no other Application, AFAIK). Curiously the samba's own logs never display such names correctly, no matter what the setting. If I comment it out the paths with non-ASCII chars which were created while the parameter was in force suddenly appear quite different on an SMB client (Win2K): 29.04.2003 21:13 <DIR> A─ 29.04.2003 21:13 <DIR> OÍ 29.04.2003 21:13 <DIR> U▄ 29.04.2003 21:13 <DIR> õa 29.04.2003 21:13 <DIR> ÷o 29.04.2003 21:14 <DIR> ▀s 29.04.2003 21:13 <DIR> ³u (To help identify the characters I used the nearest ASCII big char before the uppercase version and the nearest ASCII small char after the lowercase version of such characters). New files created after commenting the parm out retain their expected appearance on the client but look strange on Linux: drwxrwxrwx 2 root root 96 Apr 29 21:58 A? drwxrwxrwx 2 root root 96 Apr 29 21:58 O? drwxrwxrwx 2 root root 96 Apr 29 21:58 U? drwxrwxrwx 2 root root 96 Apr 29 21:58 ?a drwxrwxrwx 2 root root 96 Apr 29 21:58 ?o drwxrwxrwx 2 root root 96 Apr 29 21:58 ás drwxrwxrwx 2 root root 96 Apr 29 21:58 ?u In either case the problem does not arise so long as "character set" is commented out. Toggling the parameter back in to smb.conf makes unusable those paths with non-ASCII characters which were created while the parameter was commented out. I've watched what happens when Excel tries to open a non-writeable spreadsheet file in one of those directories with non-ASCII characters in their names while the parameter "character set" is set so that these non-ASCII characters appear as expected on both sides of the Samba server. The "filemon.exe" shows that after a convoluted quiz session between the Win2K client and Samba server the Excel program gets a "FILE NOT FOUND" result after an "IRP_MJ_CREATE" request on the subject file. However, before this error occurs the same request for this file was issued 6 more times by Excel and another 6 times by the Explorer, always returning "SUCCESS" as the result. Samba log at level 3 comes to the same conclusion: smbd/open.c:open_file(177) Error opening file A~N/a.xls (No such file or directory) (local_flags=2) (flags=2) smbd/error.c:error_packet(94) error string = No such file or directory smbd/error.c:error_packet(113) error packet at smbd/nttrans.c(889) cmd=162 (SMBntcreateX) NT_STATUS_OBJECT_NAME_NOT_FOUND At level 4 it is preceded by this diagnostic: smbd/open.c:open_file_shared1(974) calling open_file with flags=0x2 flags2=0x0 mode=0766 At level 5 we see that it was part of an SMBntcreateX transaction but still no explanation why it should conclude that there is "No such file or directory" for a perfectly existent file. I lost patience here and set the debug level to 999. It looks like it is a bug in Samba because what really happens is that "fd_open" tries to open the file with O_RDWR (with flags=0x2) and gets the error "Permission denied" because the user doesn't have the write permission for the file. Why does it then reply with "No such file ..." only if the parent directory name contains non-ASCIIs?
This is my first bug report. If you need more info, logs etc. please drop a line.
Jeremy, Can you take a look at this one? I've lowered the priority to a P3 since it looks like an extended character defect.
In my understanding the problem is that after calling fd_open the open_file then calls inherit_access_acl which never leaves any traces in debug logs but conceivably itself causes other errors ("No such file or directory" for instance), which mask the original error condition in errno ("Permission denied"). I haven't looked into it but to me it obviously makes no sense to call it before checking up if fd_open was at all successful. So the resolution of the bug would be to change the following sequence in smbd/open.c 171 fsp->fd = fd_open(conn, fname, local_flags, mode); 172 (void) inherit_access_acl(conn, fname, mode); /* DOESN'T BELONG HERE */ 173 /**xxxxxxxxxxxxxxxxxxx**/ 174 if (fsp->fd == -1) { 175 DEBUG(3,("Error opening file %s (%s) (local_flags=%d) (flags=%d)\n", 176 fname,strerror(errno),local_flags,flags)); 177 check_for_pipe(fname); 178 return False; 179 } to this 171 fsp->fd = fd_open(conn, fname, local_flags, mode); 172 173 if (fsp->fd == -1) { 174 DEBUG(3,("Error opening file %s (%s) (local_flags=%d) (flags=%d)\n", 175 fname,strerror(errno),local_flags,flags)); 176 check_for_pipe(fname); 177 return False; 178 } /**vvvvvvvvvvvvvvvvvvvvv**/ 179 (void) inherit_access_acl(conn, fname, mode); /* MAKES MORE SENSE HERE */ /**^^^^^^^^^^^^^^^^^^^^^**/ I thank you very much for teaching me to fish instead of waitinig to get the fish from you. There is obviously much more that people can do themselves. Especially if they feel that lowering of priority was unjust and makes you think what your priorities are. As it is Samba is sailing against strong winds here too. There is nothing more annoying for suits, who eventually decide on the deployment, when they can't open "büdget/Kasse.xls" because US/GB/AU developers don't hold extended character defects for high enough of a priority. It makes me feeil that it's because I is a Crout. Cheers Dragan
The proposed fix looks correct. However the bug is really against 3.0, not 2.2.8a. I have checked in the fix. Jeremy.
done
database cleanup