[nSLUG] Anyone using RH 5.1 and cifs client mount?
George N. White III
gnwiii at gmail.com
Fri Apr 4 13:52:16 ADT 2008
I've been using "mount -t cifs ..." with Fedora, Debian, Gentoo and have never
encountered this problem. I suppose the next step is to capture some
packets to collect some hard evidence for the screwup.
The Samba people have lots of experience with weird Windows "features" --
have you checked for similar issue in Samba?
On Fri, Apr 4, 2008 at 1:36 PM, D G Teed <donald.teed at gmail.com> wrote:
> I'm not getting any response on the cifs linux client mailing list,
> and I see one other person had the same problem as I see
> in late Feb, with no response.
> The correct path was working in an earlier RH kernel, but has been
> broken lately.
> I use a typical:
> mount -t cifs //winserver/Users /home/mnt/ --verbose -o
> The mount always suceeds, but I see the user's actual folder in
> something like: /home/mnt/donald/donald/donald rather than
> in expected /home/mnt/donald
> This is wonky for all user directories. ls of /home/mnt/<username> shows
> a list of all user directories again.
> I can also see all user names from ls of /home/mnt/<usernameA>/<usernameB>
> So I can get to my home dir on the Windows box by:
> cd /home/mnt/george/harry/donald
> cd /home/mnt/david/micheal/donald
> For now I've just hacked the apache conf so it works, but I'm
> a little concerned that a future kernel update will unexpectedly
> fix this and then the apache reference to the extra long path
> will be bogus.
> The target Windows machine is part of a DFS set up, but I'm
> connecting directly to one of the two nodes of that, which
> worked fine before.
> The kernel I'm using is: 2.6.18-53.1.13.el5
> I find it hard to believe this is a rare problem.
> nSLUG mailing list
> nSLUG at nslug.ns.ca
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the nSLUG