Running Samba server 3.0.0 and/or 3.0.1rc1 on Red Hat 8.0. Seems to work well with Windows XP clients (haven't tested earlier Windows versions much yet), but has lots of problems with OS/2 clients. I can use "net use" to map a drive letter to a Samba share, but when trying to open the share (or drive letter) from the WPS, it gives me error messages, and nothing is displayed. Using the OS/2 SMB Tracing Tool, we see things like this: Understands long file names, Errors in NT status format, Unknown secondary SMB flags: 0x18433 I have tried "nt status support = no" but it didn't change anything. The protocol negotiation seems to come up with LM1.2X002, which I suppose is what Samba calls LANMAN2.
By the way, the "error messages" are pretty useless: "No objects were found" and "The system call level is incorrect"
Created attachment 312 [details] tcpdump from Linux machine for OS/2 client
please retest 3.0.11 and reopen if necessary.
No change in 3.0.11.
The supplied tcpdump has truncated frames. Please redo this with the option to save *all* the frame contents. Thanks, Jeremy.
Created attachment 1114 [details] result of "tcpdump -s 0 -w tcpdump.log host <ip>" This is with Samba 3.0.13. If my tcpdump options are not adequate, please let me know what I should use instead.
(In reply to comment #0) > > .... > > I can use "net use" to map a drive letter to a Samba share, but when trying to > open the share (or drive letter) from the WPS, it gives me error messages, and > nothing is displayed. > > By the way, the "error messages" are pretty useless: "No objects were found" > and "The system call level is incorrect hello steve, jeremy this bug is a dupe of #1677! the problem is, that some code in TRANS2.C necessary for the EA (extended Atrribute) handling got lost in samba3. Because of incorrect EA handling in samba the OS/2 WPS (working with EA) is unsatisfied and reports "no object were found" - while the os/2 command line (not working with EA) works good. I made samba3 working with os/2 with some "dirty hacks" in trans2.c. I really didnt understand too much of trans2.c but i compared with samba2 and discovered that info_levels SMB_INFO_QUERY_EAS_FROM_LIST and SMB_INFO_QUERY_ALL_EAS got lost. (see bug #1677 and frank giesslers comments) So at three points in the source i added the missing lines and samba works for me. i try to attach my trans2.c - you can easily find my changes because of the DIRTY_EA_FIX_THOMAS define. Perhaps someone with more skills in trans2.c can make the code really right! thomas
Created attachment 1136 [details] modified trans2.c see reply above
Thanks, Thomas! *** This bug has been marked as a duplicate of 1677 ***
Since this came first, the other is a dupe of this. Plus, this one has a summary someone searching the bug database could logically find. The other summary is just so much gibberish to me.
Testing with Samba 3.0.15pre2, I get the same "No objects were found" dialog, followed by "SYS0282: The target file system cannot save extended attributes."
Send me a debug level 10 log showing smbd attempting to save the EA. If you're not running on a filesystem that supports EA's then you will get this message even though the bug is fixed. Jeremy.
(In reply to comment #12) > If you're not running on a filesystem that supports EA's then you will get this > message even though the bug is fixed. That's probably the case, sorry for the bug spam. I'll test on another (newer) system, and report back.
Tested 3.0.15pre2 on a FC3 system, using ext3 with ext_attr attribute enabled. Copying a file with an EA (os2krnl) via command line does not produce an error message, but no EA is created either. Opening the drive folder, produces the "No objects were found" message the first time, and creates the "WP ROOT . SF" file, although it doesn't hide it. Opening the drive folder the second time, it produces the "No objects were found" message AND "SYS0282: The target file system cannot save extended attributes."
Created attachment 1182 [details] zip of level 10 debug log
You need to tell Samba that the filesystem supports EA's. Do you have : ea support = yes set in the global section of your smb.conf ? Jeremy.
Created attachment 1183 [details] zip of level 10 debug log Doh! Looks like I missed that new parameter, added way back in 3.0.3. That fixes the subject bug, although copying files from command line is back to producing the "target file system does not support them" message. It looks like *everything* has EAs now, although it is all SELinux stuff, not OS/2 EAs.
Should I close this bug, and open a new one for remaining problem?
Yes, please log a new bug. Jeremy.
Opened bug 2661.
I rebuilt 4 days ago, and it still fails for me. I wish I could get something other than simple DIR listings to work. I can't get OS/2 to use samba shares, nor can I get Linux to use OS/2 shares. I've been told I can no longer use smbfs in fstab, but must mount with CIFS, which OS/2 does not support.