[mdlug] Samba strangeness

[David McMillan]

David Lee Lambert wrote:
> Mathew Enders wrote:
>> David McMillan wrote:
>>   
>>> 	Two items here.
>>>
>>> 	I've set up my personal file server (Jaunty) with a shared drive 
>>> mounted locally as /archive1.  This drive is shared across the network 
>>> using Samba.  I can access it from Windows and Linux machines on the 
>>> network, but:
>>>
>>> 	1:  when trying to transfer large files, the connection just seems to 
>>> stall out -- progress stops entirely.  Yet, transferring a similar-sized 
>>> cluster of smaller files doesn't have the same problem.  Transfers *are* 
>>> slower than I'd expect, but they don't choke.  Anybody know the best way 
>>> to troubleshoot this kind of problem?  I've done lots of SMB shares 
>>> (Windows and Linux) in the past, but this is a new problem for me.
>>>
>>>     
> I've seen problems like this with a network cable that was frayed, or a 
> PCMCIA network card that had been dropped, or mismatched full-duplex 
> settings.  Samba has several TCP tuning parameters, which may help.  Do 
> SSH, FTP or HTTP file transfers between those systems happen as fast as 
> you expect?  SMB seems less resilient over an imperfect network, or with 
> a slow host on either end, than other protocols.
>>> 	2:  The really weird one.  Only some files show up to the SMB clients. 
>>>   It doesn't matter if the client is Windows or Linux, so the issue has 
>>> to be on the server end.  For example, the /archive1/images directory 
>>> contains a *lot* of files, and subdirs, but only a relative handful of 
>>> the "root" files show up to SMB clients, and none of the subdirs.  I've 
>>> checked the permissions on the files/subdirs that aren't showing up, and 
>>> they're the same as on the files that *are* showing up.  Even chmod'ing 
>>> all the files to 777 didn't change anything.  Aside from the file access 
>>> permissions, what else could block files/subdirs from showing up to an 
>>> SMB client?
>>> 	It's not just a browsing thing, either -- trying to cd directly to 
>>> subdirs that I *know* are there generates a "no such directory" error.
>>>
>>>     
> Following my suggestion above,  perhaps packets are being dropped from 
> directory-listings;  but that's just a wild guess.  Samba has a lot of 
> security options;  is there any pattern to the filenames that display 
> problems?

	Not as far as I can tell -- I've checked the access permissions on all 
of them, and even gone so far as to do a chmod -R 777 on the entire 
drive just to see what would happen.  No dice.  The files that *do* show 
run the name gamut from 0-9 through a-z... hm.  It just hit me that all 
of the files I *can* see remotely start with either a number, a 
lowercase letter, or an underscore.  Nothing that starts with a capital 
letter shows up.
	...okay, I think I found it.  Don't know why it happened this way, but 
here goes:
	Under /archive1, I had both an 'Images' and an 'images' subdir (due to 
a typo a while back that I hadn't got around to cleaning up).  'Images' 
didn't have any subdirs, and only had a few files.  Both directories 
showed up to remote clients, but after some more detailed digging, it 
looks like, somehow, when I cd'd to 'images', I was actually ending up 
in 'Images'.  I can see why Windows might fail to see the difference 
between /archive1/images and /archive1/Images, and why it might default 
to the capitalized directory name, but why would even Linux clients do 
it?  Does Samba not differentiate between upper- and lower-case names?
	Anyway, moving all the images into one 'images' folder and deleting the 
extra one fixed the entire issue.

	Thanks!