Hi All 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:- 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] 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] I tried getting around that error with the xcopy /o 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. 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. Pete
On Fri, May 12, 2006 at 08:39:06PM +0100, Peter Brown wrote:> 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?We need network traces of the commands failing. Please file a bug report at https://bugzilla.samba.org/ and add the sniffs there. Thanks, Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/20060513/2b5ad175/attachment.bin
Hi Peter, ----- Original Message ----- From: "Peter Brown" <losepete@ntlworld.com> To: <samba@lists.samba.org> Sent: Friday, May 12, 2006 9:39 PM Subject: [Samba] samba 3.0.22 and OS/2 connectivity> Hi All > > 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:- > > 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] > > > > 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] > > > > I tried getting around that error with the xcopy /o 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. > > > > 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. > > Pete > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/listinfo/sambalatest samba 3.0.22 does a pretty good job regarding OS/2 connectivity - but, as often, there are some pitfalls - additional thougths and checks apply. The most basic difference of OS/2 is its usage of 'extended attributes' (EAs). Samba can handle EAs pretty well - but _only_, if the used *nix kernel and the used file system can handle EAs, too. In *nix terms, EAs are called 'xattr'. Sorry, the Linksys NSLU2 is new to me - so I had a short look into the specs. The specs claim, that 'FAT32', 'NTFS' or 'ext3' can be used... To _really_ work properly (in all cases), OS/2 needs an EA space of 64KB! Even if xattr support is compiled into the kernel - and 'ext3' is enabled (in fstab) for xattr usage: /dev/hdb6 /ext3 ext3 acl,user_xattr 1 2 xattr limitations of 'ext3' would count. 'ext3' is only able to store about 3.9KB EAs! reiserfs, JFS and XFS are file systems, which support 64KB EAs. So, if you _really_ don't need EAs to be stored onto the Linksys samba server, some entries in your smb.conf should be checked. Think twice - the OS/2 workplace shell is using EAs heavily - so you won't be able to use that GUI stuff anyway! (The WPS flags nearly _any_ EA error). Samba3 has some minor glitches, when the used file system does _not_ support EAs - but you told it to use EAs in smb.conf. (Directories - which are told to contain EAs - might be created, and short lateron an error EAS_NOT_SUPPORTED is returned... so then you have that subdir created ... but OS/2 got confused...) Peter, a 1st try to get better results should be ea support = no in smb.conf xcopy should behave much more as expected. (still sending expected EA warnings) Please post your smb.conf! Best wishes - Guenter btw - you can also reach me on irc.freenode.net channels #samba-os2 #samba-os2-technical
Hi Peter, .... cut some stuff ...> >> 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. > >> > >> Pete > >> -- > >> To unsubscribe from this list go to the following URL and read the > >> instructions: https://lists.samba.org/mailman/listinfo/samba > > > > latest samba 3.0.22 does a pretty good job regarding OS/2 connectivity - but, > > as often, there are some pitfalls - additional thougths and checks apply. > > The most basic difference of OS/2 is its usage of 'extended attributes' (EAs). > > Samba can handle EAs pretty well - but _only_, if the used *nix kernel and > > the used file system can handle EAs, too. > > In *nix terms, EAs are called 'xattr'. > > Sorry, the Linksys NSLU2 is new to me - so I had a short look into the specs. > > The specs claim, that 'FAT32', 'NTFS' or 'ext3' can be used... > > > > To _really_ work properly (in all cases), OS/2 needs an EA space of 64KB! > > Even if xattr support is compiled into the kernel - and 'ext3' is enabled (in fstab) > > for xattr usage: > > /dev/hdb6 /ext3 ext3 acl,user_xattr 1 2 > > xattr limitations of 'ext3' would count. 'ext3' is only able to store about 3.9KB EAs! > > > > reiserfs, JFS and XFS are file systems, which support 64KB EAs. > > > Sadly ext3 is the filesystem used by the NSLU2 and must be used on the > 1st partition of any disk that the NSLU2 is "Unslung" to. > > Alternative filesystems do not seem to include jfs (a more natural > choice for an OS/2 user) or xfs - in fact we are talking fat, fat32 and > ntfs as alternatives according to this doc > http://www.nslu2-linux.org/wiki/Unslung/R63DiskBehaviour > > > > > > So, if you _really_ don't need EAs to be stored onto the Linksys samba server, some > > entries in your smb.conf should be checked. > > Think twice - the OS/2 workplace shell is using EAs heavily - so you won't be > > able to use that GUI stuff anyway! (The WPS flags nearly _any_ EA error). > > > Maybe I got too used to the fact that the samba 2.?.?? used in the > Linksys firmware v23r29 worked fine? > > > > > > Samba3 has some minor glitches, when the used file system does _not_ support > > EAs - but you told it to use EAs in smb.conf. > > (Directories - which are told to contain EAs - might be created, and short lateron an > > error EAS_NOT_SUPPORTED is returned... so then you have that subdir > > created ... but OS/2 got confused...) > > > > Peter, a 1st try to get better results should be > > ea support = no > > in smb.conf > > > Extremely Bad move - End of graphical access to the samba shares from an > OS/2 based system. > > That is Not acceptable. > > I may be able to cope with command line access but I do not expect other > users here to be able to cope. Access using the network gui is a necessity. > > Based on the above advice I must reconsider whether "Unslinging" the > NSLU2 has been a good move. No doubt it brings many improvements - and > fixes - over the Linksys standard firmware but it also introduces > problems as regards samba. > > Interestingly I have discussed this problem before when querying the > behaviour of samba 3.0.11 > > The response was: > > "I probably fixed all these issues concerning File services with Jeremy > about release 3.0.16. > So 3.0.20a shold work fine." > > > Looks like the problems have resurfaced in 3.0.22 :-( > > > > xcopy should behave much more as expected. (still sending expected EA warnings) > > Please post your smb.conf! > > > Must admint that there is more than a good possibility that I've got > something wrong in that file - especially as I now find that I cannot > open the smb.conf file from my OS/2 system; "access denied". > > That is behaviour that has changed since yesterday when I did try some > "fine tuning" but I do not see what is causing the access denied as I am > logged on using an Administrator login. > > > The below is copied from the "Full View" using SWAT - and seems to > include a lot that is not actually in the smb.conf that I last edited > using a text editor......cut your smb.conf ...> > Thanks > > PeteBelieve me, samba 3.0.22 _is_ doing a really good job regarding os/2 connectivity. :-) (And I know, what I talk about ... did hundreds of tests in the past...) My intention was, to do a step by step approach to solve your needs. The suggestion to do a 1st try with ea support = no in smb.conf was related to your 'xcopy' anomalies, you described before. Are your xcopy anomalies gone, when you change that in smb.conf? My guess is, that your kernel and/or ext3 file system does not handle xattr correctly at all. (== no xattr support available). That is _not_ a samba fault! To simulate your system, I added a 'ext3noxattr' mount to my linux test box. Excerpt from fstab: /dev/hdb6 /ext3 ext3 acl,user_xattr 1 2 /dev/hdb9 /ext3noxattr ext3 acl 1 2 When I set 'ea support = yes' - and access 'ext3noxattr' shared by samba from os/2 - I see the xcopy anomalies, you have talked about. When 'ea support = no' is set, I'm able to copy my whole os/2 boot drive over to that samba share! Yes, there are lots of EA warning displayed - but that is expected. The max. ext3 EA size of about 3.9KB must not be a killer to be usable by os/2. Most os/2 EA sizes are much lower, but not all. :-( (I know some os/2 guys, which _always_ use ext2 or ext3 on external samba boxes - apps like PMVIEW have troubles, cause it is using large EAs to store thumbnails of the bitmaps for preview purpose. In such cases, they mount reiserfs or xfs). So, could it be possible, to tell your Linksys box to use xattr?! Sorry, I really have no deeper knowledge about that Linksys NSLU2. May be, you can shed some light about the internals. - what operating is running? - do you have some sort of shell access (telnet, ssh, ...)? - what parms can be modified/tuned? - ...? Peter, I've written a native os/2 test applet 'testmaxea.exe', which checks the max. supported EA size on any local or network shared drive. If you like, I can email it. Good luck - Guenter