[mdlug] Samba strangeness

[Jeff Hanson]

Because Samba has to suppress case differences over SMB for Windows.
It probably doesn't differentiate between clients.

I suspect Wine has similar issues with Windows apps when there are two
files in the same location whose names differ by case only.  It's
annoying to deal with when you try to extract an update out of a zip
file that is intended to overwrite existing files in a directory but
the name cases differ.

On 1/3/10, David McMillan <skyefire at skyefire.org> wrote:
> 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!
>
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug
>