[linux-cifs-client] cifs mounted home directory problems

[Åge Strand]

Hi,

Is there a workaround or fix for the ':' problem? It still seems to be a
problem, even in linux kernel 2.6.10 /Samba 3.0.10. ...or I might very
well have overlooked some inanely obvious setting that solves this darn
thing.

I'm trying to set up a Samba server on a Linux (2.6.10) box which will
be serving home dirs for Linux users. I don't want to use NFS, so I
hoped smb or cifs would do the trick.
I'm using pam_mount to set this up - and it works, as far as mounting
goes. The problem is Evolution, KDE and other apps that use filenames
with the colon character (':') in them.

Doing a stat on one of these files tells me quite rightly that it is a
regular file and all looks well up to that point, but if I try to cat
one of these files I get an error message saying "Not a directory".
Well of course it's not a directory! stat just told me it's a regular
file... grrrr! At this point frustration got the best of me, hence this
email. :-)

Any suggestions are welcome...


Oggy

>> The actual path is this:
>>  \.camel_certs\ba:aa:aa:aa:aa:aa    etc.
> 
> Arrgggghhh.    ':'  is an invalid character in a cifs filename.  With 
> one excpetion - presumably it could indicate a data stream (which Samba 
> 3 would not support in any case) - in which case file file /.camel/ba 
> would need to exist for the stream name after the : to make sense    :)
> 
> Presumably this is not some cross platform app that has some friendly 
> configure option to work around illegal characters in file names right ...
> 
> Anyone know what this looks like (ie creating a filename with a :  in it 
> on Windows) when a Windows system has the Windows SFU (Service for Unix) 
> installed which IIRC is a free download?  Perhaps they use the POSIX 
> flag in the Open request to bypass the name check??  Would be easy 
> enough to see what flows on the wire - and what it looks like on t2 
> FindFirst when you see a locally created weird filename in a directory
> 
> jra,
> Any chance you can turn off the checking for valid Unix, invalid Windows 
> characters, for cases when Unix extensions are negotiated are for POSIX 
> flag or client?
> 
> By the way this does show a bug in Samba 3  e.g.
> 
>     echo "some data" > /mnt/1a:aa
> fails to Samba 3 with (a not a directory error - which can't be right), 
> while it succeeds to Windows (which implicitly creates the file 1a, and 
> presumably the associated "stream" aa     Presumably since Samba 3 does 
> not support streams that is part of the problem - but the file (zero 
> length) is implicitly created as a side effect (perhaps someone could 
> try this experiment to a Windows FAT partition and see what error 
> Windows returns, if any,when you try to create the file remotely with a :  
> 
> My guess is that if we fix Samba to match Windows behavior that would 
> get past a few of the app problems - although not solve the problem of 
> how to deal with readdir not listing the file in the directory listing.  
> Note that both lookup and stat from my client to Windows (for the file 
> "1a:aa") work and return expected results as if it were a distinct file 
> (that is how streams are expected work so I should not have been 
> surprised).   I hate to wait for Samaba4 to fix this with streams when 
> really this should not be a streams issue.