The Samba-Bugzilla – Bug 872
opening folders from OS/2 client failures
Last modified: 2005-04-28 07:41:30 UTC
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,
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
Perhaps someone with more skills in trans2.c can make the code really right!
Created attachment 1136 [details]
see reply above
*** 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.
(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 ?
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.
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.