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
Could you please add network traces and debug level 10 logfiles of smbd to this bug report? Thanks, Volker
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
Created attachment 1902 [details] requested samba log
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.
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
Created attachment 1904 [details] log.smbd "zipped" to overcome the upload size restriction
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
(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
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
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