Bug 3774 - samba 3.0.22 and OS/2 connectivity - OS/2 can read but not write to the samba shares
samba 3.0.22 and OS/2 connectivity - OS/2 can read but not write to the samba...
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.22
Other OS/2
: P3 normal
: none
Assigned To: Guenter Kukkukk
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-13 12:35 UTC by Pete
Modified: 2011-03-21 19:26 UTC (History)
2 users (show)

See Also:


Attachments
the result of issuing the command tcpdump -i lan0 -n -s 1514 -w tcpdump.log on an OS/2 based system (98.25 KB, application/octet-stream)
2006-05-13 20:14 UTC, Pete
no flags Details
requested samba log (39.08 KB, application/octet-stream)
2006-05-13 20:19 UTC, Pete
no flags Details
Capture file from running tcpdump (517.71 KB, application/octet-stream)
2006-05-14 09:47 UTC, Pete
no flags Details
log.smbd "zipped" to overcome the upload size restriction (70.27 KB, application/zip)
2006-05-14 11:23 UTC, Pete
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pete 2006-05-13 12:35:37 UTC
I have a Linksys NSLU2 device which is used to hook USB2 drives upto my network as network attached storage.

The Linksys firmware upgrade for this device includes samba 3.0.11 which is a non-starter regarding OS/2 connectivity.

There is an alternative firmware based on the Linksys firmware called Unslung from http://www.nslu2-linux.org/

The Unslung firmware allows "unslinging" the operating system from firmware to disk and allows upgrade and additional packages.

Having followed the instructions carefully I managed to "Unsling" the NSLU2 and apply the samba 3.0.22 upgrade available for this system.

After a bit of hunting around I managed to find the smb.conf parameter that allows OS/2 based systems to access samba shares and can now read from the shares fine.

What I cannot do is write easily to any of the shares; ie Selecting a folder on my local drive and dragging it to a shared folder on the NSLU2 results in this OS/2  error when using the graphical interface:-

SYS0266 : The specified file was not copied


Inspecting the shared folder reveals that the folder has been created but is empty - no file copying performed.


I investigated command line alternatives to copying files using xcopy with some strange results.

In these screensnaps S: is a mapped drive of the nslu2 share /disk2 aka "For everyone"


[S:\Pete]xcopy i:\temp temp /s /e /v /h /t /r
The current target for XCOPY, temp,
can be a directory or file name and must be specified.  Respond Y
if the target is a directory or N if the target is a file name.

Does temp specify a directory (Y/N)? y
SYS1693: The system cannot create the directory.


0 file(s) copied.


[S:\Pete]


The above failed because it was not possible to create a directory temp on the samba share during the copy process.


If I make a directory, change to that directory and then perform an xcopy it works:-

[S:\Pete\temp]xcopy j:\temp\* /s /e /v /h /t /r
The extended attributes for the file or directory were
discarded because the target file system does not support them.

The extended attributes for the file or directory were
discarded because the target file system does not support them.


Source files are being read...

J:\temp\History.txt
J:\temp\ide.txt
J:\temp\OS2_Install.exe
J:\temp\OS2_UnZip.exe
J:\temp\WDSibyl.dat

5 file(s) copied.


[S:\Pete\temp]



But if the source contains a subdirectory I get an error and the whole process stops:-


[S:\Pete\temp]md PostArmor

[S:\Pete\temp]cd PostArmor

[S:\Pete\temp\PostArmor]xcopy j:\PostArmor\* /s /e /v /h /t /r
The extended attributes for the file or directory were
discarded because the target file system does not support them.

The extended attributes for the file or directory were
discarded because the target file system does not support them.


Source files are being read...

SYS1248: A subdirectory or file S:\Pete\temp\PostArmor\docs already exists.


0 file(s) copied.


[S:\Pete\temp\PostArmor]


The "subdirectory or file S:\Pete\temp\PostArmor\docs" only exists because it was created during the above copying process...


I tried getting around that error with the xcopy /o (overwrite existing files) parameter:-


[S:\Pete\temp\PostArmor]xcopy j:\PostArmor\* /s /e /v /h /t /r /o
The extended attributes for the file or directory were
discarded because the target file system does not support them.

The extended attributes for the file or directory were
discarded because the target file system does not support them.


Source files are being read...

The extended attributes for the file or directory were
discarded because the target file system does not support them.

SYS1248: A subdirectory or file S:\Pete\temp\PostArmor\docs\images already exists.


0 file(s) copied.


Even trying to force the issue using the /o parameter does not work...


I am not really sure if this a bug or a misconfiguration - there is a lack of info on configuraing samba to work with OS/2 so there is a good chance this is a misconfiguration.

Needless to say whatever I have done to the samba configuration does not seem to upset Windows2000 - I can startup my VPC w2k installation and have no problems at all accessing the nslu2 shares for reading and writing...

I am now starting to wonder if there is something a little flaky as regards samba 3.0.22 and OS/2 connectivity? - or is there some secret parameter I've missed in the smb.conf file?

Any/All help appreciated. 

Regards

Pete
Comment 1 Volker Lendecke 2006-05-13 12:48:45 UTC
Could you please add network traces and debug level 10 logfiles of smbd to this bug report?

Thanks,

Volker
Comment 2 Pete 2006-05-13 20:14:49 UTC
Created attachment 1901 [details]
the result of issuing the command tcpdump -i lan0 -n -s 1514 -w tcpdump.log on an OS/2 based system

Hope it shows where the problem is
Comment 3 Pete 2006-05-13 20:19:04 UTC
Created attachment 1902 [details]
requested samba log
Comment 4 Pete 2006-05-14 09:47:27 UTC
Created attachment 1903 [details]
Capture file from running tcpdump

Apologies - I previously uploaded tcpdump.log which was not the file requested and is probably of no use.
Comment 5 Volker Lendecke 2006-05-14 10:01:48 UTC
Some points:

First, the tcpdump.log IS the usable file, the third attachment you added is not.

Second, the log file you uploaded is not complete. Do you have 'max log file' set to something like 50? Please dramatically increase that.

Third, is it possible that the file system you are using on the Linux side does not support extended attributes? From the sniff you can see that setting xattrs fails.

Volker
Comment 6 Pete 2006-05-14 11:23:02 UTC
Created attachment 1904 [details]
log.smbd "zipped" to overcome the upload size restriction
Comment 7 Volker Lendecke 2006-05-14 11:47:06 UTC
Except for the fact that you should not share the tdb files, it seems that 3.0.22 has some weird problems with OS/2 calls.

Jeremy, the last logfile attached might be worth looking at, you had been working on it recently.

Volker
Comment 8 Pete 2006-05-15 14:04:00 UTC
(In reply to comment #5)
> Some points:
> 
> First, the tcpdump.log IS the usable file, the third attachment you added is
> not.


Sorry, was not sure if you wanted machine readable or human readable output...


> 
> Second, the log file you uploaded is not complete. Do you have 'max log file'
> set to something like 50? Please dramatically increase that.


New log already attached.


> 
> Third, is it possible that the file system you are using on the Linux side does
> not support extended attributes? From the sniff you can see that setting xattrs
> fails.
>


Ummm... Not sure; my knowledge of linux filesystems = 0

The disk is formatted ext3.

I wonder if the "xattrs" mentioned are set as a result of the smb.conf line
ea support=Yes

Without that line an OS/2 system cannot even "see" the shares using the network graphical interface ; attempting to open any shared folder results in error messages like "No objects were found that matched the search criteria" followed by "Incorrect system call".

Regards

Pete

Comment 9 Guenter Kukkukk 2006-10-26 18:57:11 UTC
Hi all,

just noticed that this bug is still marked as NEW.
I had further discussions with Pete using private
email exchange.

One of the main problem for Pete was, that the Linksys NSLU2
device only allows limited access to all involved components
(kernel, filesystems, ...)

The used ext3 fs was not able to store any EAs - checked with
tstmaxeas.exe - possibly due to no kernel xattr support.

So I suggest to mark this one as fixed (or similar).

Note:
This will not answer the question, how samba _exactly_
should behave (i.e. error return codes), when
  ea support = No
is specified.
Much more investigation has to be done to track that down.
(if that ever could be done right on the server side...) 

Cheers, Guenter Kukkukk
Comment 10 Björn Jacke 2011-03-21 19:26:39 UTC
Günther, is there anything that changed here since you wrote comment #9 ?
I'll assign this one to you, you might want to update the status or just close it as you suggested already ... thanks Björn