Thread: [Devil-linux-develop] Problem with mount.cifs

Dears

Starting with RC2 32-bit only (from kernel 3.1.7) I can't mount using 
mount.cifs. This Samba served directory is on Edimax NS-2502 NAS small server, 
so maybe is not typical, but as for now, worked well. Probably issue is with 
cifs-utils, added with upgrade from 3.1.6 to 3.1.7, so probably mount.cifs 
from cifs-utils works different then mount.cifs from samba package. mount.cifs 
gives the following:

> # mount.cifs //172.27.32.83/RAID /mnt -o user=***,password=*****
> Unable to resolve (null) to canonical path: Invalid argument

This same script is working OK with DL compiled with kernel 3.1.6 and earlier 
and with subsequent DL (up to last kernel 3.2.4) but only in x86_64 version.

In Internet I can't find solution. Maybe in DL should be installed mount.cifs 
from samba, not from cifs-utils?

Regards

-- 
Andrzej Odyniec

Andrzej

The addition of cifsutils was in preparation of the upgrade to samba 3.6.
The new samba version doesn't include any of the cifs client tools, that's
why we need that package.

I just checked in the latest samba and an update to cifsutils. Hopefully the
newer version works better for you.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Wednesday, February 08, 2012 12:37 PM
> To: dev...@li...
> Subject: [Devil-linux-develop] Problem with mount.cifs
> 
> Dears
> 
> Starting with RC2 32-bit only (from kernel 3.1.7) I can't mount using
> mount.cifs. This Samba served directory is on Edimax NS-2502 NAS small
> server, so maybe is not typical, but as for now, worked well. Probably
issue is
> with cifs-utils, added with upgrade from 3.1.6 to 3.1.7, so probably
mount.cifs
> from cifs-utils works different then mount.cifs from samba package.
> mount.cifs gives the following:
> 
> > # mount.cifs //172.27.32.83/RAID /mnt -o user=***,password=*****
> > Unable to resolve (null) to canonical path: Invalid argument
> 
> This same script is working OK with DL compiled with kernel 3.1.6 and
earlier
> and with subsequent DL (up to last kernel 3.2.4) but only in x86_64
version.
> 
> In Internet I can't find solution. Maybe in DL should be installed
mount.cifs
> from samba, not from cifs-utils?
> 
> Regards
> 
> --
> Andrzej Odyniec
> 
> 
>
----------------------------------------------------------------------------
--
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Heiko Zuerker wrote:
> The addition of cifsutils was in preparation of the upgrade to samba 3.6.
> The new samba version doesn't include any of the cifs client tools, that's
> why we need that package.

Heiko,

You are right. I did not check carefully the cause. Now I'm wiser, because I 
read the sources.

> I just checked in the latest samba and an update to cifsutils. Hopefully the
> newer version works better for you.

Before I wrote first mail, I checked the same with these new versions of samba 
and cifs-utils. It did not solve the problem. Anyway, thanks for the upgrade.

The problem is with realpath function, which is used in mount.cifs to 
canonicalize mount point path. Two specifications are used for this function: 
one assumes that the second argument is obvious pointer to the buffer for 
canonicalized path, and the second allows to NULL pointer, when realpath 
should malloc memory for that buffer. mount.cifs uses second form and gives 
NULL pointer to this call, but for some reason (for me at least), realpath is 
not accepting NULL in the second parameter and gives error. Well, only in 
32-bit compilation. Maybe because of some additional packages, added myself, 
cifs-utils catch invalid library? I have to find the cause or patch cifs-utils.

Regards

-- 
Andrzej Odyniec

Hey,


Quoting Andrzej Odyniec <an...@ma...>:
> Heiko Zuerker wrote:
>> The addition of cifsutils was in preparation of the upgrade to samba 3.6.
>> The new samba version doesn't include any of the cifs client tools, that's
>> why we need that package.
>
> Heiko,
>
> You are right. I did not check carefully the cause. Now I'm wiser, because I
> read the sources.
>
>> I just checked in the latest samba and an update to cifsutils. Hopefully the
>> newer version works better for you.
>
> Before I wrote first mail, I checked the same with these new  
> versions of samba
> and cifs-utils. It did not solve the problem. Anyway, thanks for the upgrade.
>
> The problem is with realpath function, which is used in mount.cifs to
> canonicalize mount point path. Two specifications are used for this function:
> one assumes that the second argument is obvious pointer to the buffer for
> canonicalized path, and the second allows to NULL pointer, when realpath
> should malloc memory for that buffer. mount.cifs uses second form and gives
> NULL pointer to this call, but for some reason (for me at least), realpath is
> not accepting NULL in the second parameter and gives error. Well, only in
> 32-bit compilation. Maybe because of some additional packages, added myself,
> cifs-utils catch invalid library? I have to find the cause or patch  
> cifs-utils.

Does the version I built work for you?

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

Heiko Zuerker wrote:
> Does the version I built work for you?

I usually build my mod version. Today I built clean from default config 
without any mods. Result is identical - mount.cifs isn't working.

Now I wil run another build after your updates.

BTW. if that does not have any effect, I will look for deeper. I will try 
catch this broken realpath. It is only matter of time.

Best regards

-- 
Andrzej Odyniec

Heiko,

>>Does the version I built work for you?
I checked Your 32-bit compilation downloaded from Sourceforge.
mount.cifs is working improperly too, that is: not working at all.

> BTW. if that does not have any effect, I will look for deeper. I will try 
> catch this broken realpath. It is only matter of time.

As promised, I diagnosed the cause of the error. It happens because of 
improper build of glibc. Probably compatibility variables are improperly set. 
Maybe SHLIB_COMPAT or another, from which it is dependent. Because of this, in 
32-bit compilation is used to compile and build of stdlib and to build symbol 
realpath in symbol table of libc not __realpath but __old_realpath. With body 
of __old_realpath as called by realpath symbol, program mount.cifs "as is" 
will not work.

Especially in lfssystem32 (after cr) libc is correct and this same, just 
compiled mount.cifs is working correctly.

When I find time, I will try to construct patch and send. Now is the reporting 
period and I have a lot of other work.

Best Regards

-- 
Andrzej Odyniec

I wrote:
> As promised, I diagnosed the cause of the error. It happens because of
> improper build of glibc. Probably compatibility variables are improperly set.
> Maybe SHLIB_COMPAT or another, from which it is dependent.
SHLIB_COMPAT should select correct version, because this old version was
accepted up to 2.3 but now is 2.12 (ofcourse, if SHLIB_COMPAT macro is working well). Maybe libc
was built correctly but for 32-bit build to CDROM is inserted improper, old version of libc?

Best regards

-- 
Andrzej Odyniec

Quoting Andrzej Odyniec <an...@ma...>:

> I wrote:
>> As promised, I diagnosed the cause of the error. It happens because of
>> improper build of glibc. Probably compatibility variables are  
>> improperly set.
>> Maybe SHLIB_COMPAT or another, from which it is dependent.
> SHLIB_COMPAT should select correct version, because this old version was
> accepted up to 2.3 but now is 2.12 (ofcourse, if SHLIB_COMPAT macro  
> is working well). Maybe libc
> was built correctly but for 32-bit build to CDROM is inserted  
> improper, old version of libc?

I don't see a reason why the 32bit version should differ from the  
64bit, but of course there could always be a problem with a configure  
script.

Do you think the problem is in the glibc? We could try building with  
2.14.1 and see if that fixes the issue.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

Heiko,

> I don't see a reason why the 32bit version should differ from the  
> 64bit, but of course there could always be a problem with a configure  
> script.

I don't see, too.

> Do you think the problem is in the glibc? We could try building with  
> 2.14.1 and see if that fixes the issue.

Yes, I think, but I'm don shure yet. This need some tests or debug.

There is no doubt: mount.cifs before any mounting is making the following:
-- cd to mountpoint directory and after
-- realpath of directory "."

And this error message is preset only in one place: after unsuccesfull realpath.

mount.cifs has no his own realpath (as many packages have), but is using one 
from libc linked dynamically:

> root:/build/tmp# objdump -t cifs-utils-5.3/mount.cifs |grep realpath
> 00000000       F *UND*  00000000              realpath@@GLIBC_2.3

and this version of realpath is needed by mount.cifs.
> root:/build/tmp# objdump -t /lib/libc-2.12.2.so |grep realpath
> 00000000 l    df *ABS*  00000000              realpath_chk.c
> 00037960 l     F .text  00000512              __realpath
> 00108080 l     F .text  00000041              __old_realpath
> 00108080 g     F .text  00000041              realpath@GLIBC_2.0
> 00037960 g     F .text  00000512              realpath@@GLIBC_2.3
> 000e3030 g     F .text  00000038              __realpath_chk

As You remebmer, standardizers changed last argument of realpath, 
disallowing/allowing null pointer. old-realpath disallows this but realpath 
allows. mount.cifs uses null pointer in this place. So realpath@@GLIBC_2.3 
used by mount.cifs in libc points to __realpath. This is correct.

libc-*.so is the only library in system, which has .text for *UND* named 
realpath@@GLIBC_2.3, so problem must be in dynamic linking of this entry or in 
the libc. As for now I'm not sure, where is problem. Error can be in broken 
__realpath binaries (not in __old_realpath), assuming compiler code generator 
error, or in dynamic linker too.

Anyway, in source code, (look at glibc-*/stdlib/canonicalize.c) this error 
(EINVAL) is returned in two places only: in __realpath, when first parameter 
is null and in __old_realpath, when the second parameter is null (this is our 
situation). __old_realpath is cover for __realpath.

If this same binaries of mount.cifs in build system work but in main system -- 
does not --- problem is probably with linked library.

But as you know, there is no certainty.

Best regards

-- 
Andrzej Odyniec

Hi,

There is a list of 32-bit apps in devil-linux-1.6.0-RC2-x86_64:


/bin/vconfig: ELF 32-bit LSB executable
/lib/firmware/mixart/miXart8.elf: ELF 32-bit MSB executable
/usr/lib/libg++.so.2.7.2: ELF 32-bit LSB shared object
/usr/lib/libg++-3-libc6.2-2-2.8.1.3.so: ELF 32-bit LSB shared object
/usr/lib/libstdc++.so.2.7.2.8: ELF 32-bit LSB shared object
/usr/lib/libstdc++.so.2.8: ELF 32-bit LSB shared object
/usr/lib/libstdc++.so.2.9.0: ELF 32-bit LSB shared object
/usr/lib/libstdc++-3-libc6.1-2-2.10.0.so: ELF 32-bit LSB shared object
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so: ELF 32-bit LSB shared object
/usr/lib/libstdc++-libc6.1-1.so.2: ELF 32-bit LSB shared object
/usr/libexec/webmin/mount/freebsd-mounts-3: ELF 32-bit LSB executable
/usr/libexec/webmin/mount/freebsd-mounts-4: ELF 32-bit LSB executable
/usr/libexec/webmin/mount/freebsd-mounts-5: ELF 32-bit LSB executable

  I excluded grub related files which is obviously can be only 32-bit (grub-0.9.x).

PS. I paid special attention in my DL_64 build system to prevent mixed lib (32 & 
64) environment - it leads really weird  side-effect.

PPS. I'm working on network scrips, ad it should eliminate the problem with 
vconfig, IP aliases etc. No ETA yet, but there is only one problem remain - 
realization of sorted graph algorithm on bash - I'm added dependencies into the 
network scripts.


Serge

Hey,

I removed the 32 bit libstdc++ from the 64 bit build.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


> -----Original Message-----
> From: Serge Leschinsky [mailto:ser...@gm...]
> Sent: Friday, February 17, 2012 2:13 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Problem with mount.cifs
> 
> Hi,
> 
> There is a list of 32-bit apps in devil-linux-1.6.0-RC2-x86_64:
> 
> 
> /bin/vconfig: ELF 32-bit LSB executable
> /lib/firmware/mixart/miXart8.elf: ELF 32-bit MSB executable
> /usr/lib/libg++.so.2.7.2: ELF 32-bit LSB shared object
> /usr/lib/libg++-3-libc6.2-2-2.8.1.3.so: ELF 32-bit LSB shared object
> /usr/lib/libstdc++.so.2.7.2.8: ELF 32-bit LSB shared object
> /usr/lib/libstdc++.so.2.8: ELF 32-bit LSB shared object
> /usr/lib/libstdc++.so.2.9.0: ELF 32-bit LSB shared object
> /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so: ELF 32-bit LSB shared object
> /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so: ELF 32-bit LSB shared object
> /usr/lib/libstdc++-libc6.1-1.so.2: ELF 32-bit LSB shared object
> /usr/libexec/webmin/mount/freebsd-mounts-3: ELF 32-bit LSB executable
> /usr/libexec/webmin/mount/freebsd-mounts-4: ELF 32-bit LSB executable
> /usr/libexec/webmin/mount/freebsd-mounts-5: ELF 32-bit LSB executable
> 
>   I excluded grub related files which is obviously can be only 32-bit
(grub-
> 0.9.x).
> 
> PS. I paid special attention in my DL_64 build system to prevent mixed lib
(32
> &
> 64) environment - it leads really weird  side-effect.
> 
> PPS. I'm working on network scrips, ad it should eliminate the problem
with
> vconfig, IP aliases etc. No ETA yet, but there is only one problem remain
-
> realization of sorted graph algorithm on bash - I'm added dependencies
into
> the network scripts.
> 
> 
> Serge
> 
>
----------------------------------------------------------------------------
--
> Virtualization & Cloud Management Using Capacity Planning Cloud computing
> makes use of virtualization - but cloud computing also focuses on allowing
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Hey,

I did a quick test about going to glibc 2.14.1.
Unfortunately a lot of things are breaking, so this is not really an option
since I don't want to delay the 1.6 release any further.

Hopefully you'll find a better solution to the issue.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Friday, February 17, 2012 9:41 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Problem with mount.cifs
> 
> Heiko,
> 
> > I don't see a reason why the 32bit version should differ from the
> > 64bit, but of course there could always be a problem with a configure
> > script.
> 
> I don't see, too.
> 
> > Do you think the problem is in the glibc? We could try building with
> > 2.14.1 and see if that fixes the issue.
> 
> Yes, I think, but I'm don shure yet. This need some tests or debug.
> 
> There is no doubt: mount.cifs before any mounting is making the following:
> -- cd to mountpoint directory and after
> -- realpath of directory "."
> 
> And this error message is preset only in one place: after unsuccesfull
> realpath.
> 
> mount.cifs has no his own realpath (as many packages have), but is using
one
> from libc linked dynamically:
> 
> > root:/build/tmp# objdump -t cifs-utils-5.3/mount.cifs |grep realpath
> > 00000000       F *UND*  00000000              realpath@@GLIBC_2.3
> 
> and this version of realpath is needed by mount.cifs.
> > root:/build/tmp# objdump -t /lib/libc-2.12.2.so |grep realpath
> > 00000000 l    df *ABS*  00000000              realpath_chk.c
> > 00037960 l     F .text  00000512              __realpath
> > 00108080 l     F .text  00000041              __old_realpath
> > 00108080 g     F .text  00000041              realpath@GLIBC_2.0
> > 00037960 g     F .text  00000512              realpath@@GLIBC_2.3
> > 000e3030 g     F .text  00000038              __realpath_chk
> 
> As You remebmer, standardizers changed last argument of realpath,
> disallowing/allowing null pointer. old-realpath disallows this but
realpath
> allows. mount.cifs uses null pointer in this place. So realpath@@GLIBC_2.3
> used by mount.cifs in libc points to __realpath. This is correct.
> 
> libc-*.so is the only library in system, which has .text for *UND* named
> realpath@@GLIBC_2.3, so problem must be in dynamic linking of this entry
> or in the libc. As for now I'm not sure, where is problem. Error can be in
> broken __realpath binaries (not in __old_realpath), assuming compiler code
> generator error, or in dynamic linker too.
> 
> Anyway, in source code, (look at glibc-*/stdlib/canonicalize.c) this error
> (EINVAL) is returned in two places only: in __realpath, when first
parameter
> is null and in __old_realpath, when the second parameter is null (this is
our
> situation). __old_realpath is cover for __realpath.
> 
> If this same binaries of mount.cifs in build system work but in main
system --
> does not --- problem is probably with linked library.
> 
> But as you know, there is no certainty.
> 
> Best regards
> 
> --
> Andrzej Odyniec
> 
>
----------------------------------------------------------------------------
--
> Virtualization & Cloud Management Using Capacity Planning Cloud computing
> makes use of virtualization - but cloud computing also focuses on allowing
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

I just had another thought, maybe one of the glibc patches we're using is
causing the issue.

You could try building with an empty glibc-patches directory.
After the "make unpack", simply empty the directory before you do the "make
all".

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


> -----Original Message-----
> From: Heiko Zuerker [mailto:he...@zu...]
> Sent: Sunday, February 19, 2012 12:19 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Problem with mount.cifs
> 
> Hey,
> 
> I did a quick test about going to glibc 2.14.1.
> Unfortunately a lot of things are breaking, so this is not really an
option since
> I don't want to delay the 1.6 release any further.
> 
> Hopefully you'll find a better solution to the issue.
> 
> --
> 
> Regards
>    Heiko Zuerker
>    http://www.devil-linux.org
> 
> > -----Original Message-----
> > From: Andrzej Odyniec [mailto:an...@ma...]
> > Sent: Friday, February 17, 2012 9:41 AM
> > To: dev...@li...
> > Subject: Re: [Devil-linux-develop] Problem with mount.cifs
> >
> > Heiko,
> >
> > > I don't see a reason why the 32bit version should differ from the
> > > 64bit, but of course there could always be a problem with a
> > > configure script.
> >
> > I don't see, too.
> >
> > > Do you think the problem is in the glibc? We could try building with
> > > 2.14.1 and see if that fixes the issue.
> >
> > Yes, I think, but I'm don shure yet. This need some tests or debug.
> >
> > There is no doubt: mount.cifs before any mounting is making the
following:
> > -- cd to mountpoint directory and after
> > -- realpath of directory "."
> >
> > And this error message is preset only in one place: after unsuccesfull
> > realpath.
> >
> > mount.cifs has no his own realpath (as many packages have), but is
> > using
> one
> > from libc linked dynamically:
> >
> > > root:/build/tmp# objdump -t cifs-utils-5.3/mount.cifs |grep realpath
> > > 00000000       F *UND*  00000000              realpath@@GLIBC_2.3
> >
> > and this version of realpath is needed by mount.cifs.
> > > root:/build/tmp# objdump -t /lib/libc-2.12.2.so |grep realpath
> > > 00000000 l    df *ABS*  00000000              realpath_chk.c
> > > 00037960 l     F .text  00000512              __realpath
> > > 00108080 l     F .text  00000041              __old_realpath
> > > 00108080 g     F .text  00000041              realpath@GLIBC_2.0
> > > 00037960 g     F .text  00000512              realpath@@GLIBC_2.3
> > > 000e3030 g     F .text  00000038              __realpath_chk
> >
> > As You remebmer, standardizers changed last argument of realpath,
> > disallowing/allowing null pointer. old-realpath disallows this but
> realpath
> > allows. mount.cifs uses null pointer in this place. So
> > realpath@@GLIBC_2.3 used by mount.cifs in libc points to __realpath.
This
> is correct.
> >
> > libc-*.so is the only library in system, which has .text for *UND*
> > named realpath@@GLIBC_2.3, so problem must be in dynamic linking of
> > this entry or in the libc. As for now I'm not sure, where is problem.
> > Error can be in broken __realpath binaries (not in __old_realpath),
> > assuming compiler code generator error, or in dynamic linker too.
> >
> > Anyway, in source code, (look at glibc-*/stdlib/canonicalize.c) this
> > error
> > (EINVAL) is returned in two places only: in __realpath, when first
> parameter
> > is null and in __old_realpath, when the second parameter is null (this
> > is
> our
> > situation). __old_realpath is cover for __realpath.
> >
> > If this same binaries of mount.cifs in build system work but in main
> system --
> > does not --- problem is probably with linked library.
> >
> > But as you know, there is no certainty.
> >
> > Best regards
> >
> > --
> > Andrzej Odyniec
> >
> >
>
----------------------------------------------------------------------------
> --
> > Virtualization & Cloud Management Using Capacity Planning Cloud
> > computing makes use of virtualization - but cloud computing also
> > focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > Devil-linux-develop mailing list
> > Dev...@li...
> > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 
>
----------------------------------------------------------------------------
--
> Virtualization & Cloud Management Using Capacity Planning Cloud computing
> makes use of virtualization - but cloud computing also focuses on allowing
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Hey,

Quoting Andrzej Odyniec <an...@ma...>:
> As You can see, mount.cifs found realpath not in glibc but in libsafe (!).
>
>> root@DesignerVM32:/var # objdump -t /lib/libsafe.so.2|grep realpath
>> 0000501c l     O .bss   00000004              real_realpath.4419
>> 00001ec0 g     F .text  00000154              realpath
>
> Indeed, in libsafe library realpath function is present, perhaps  
> safer because
> of protecting second argument from overflow, but probably not accepting (at
> least 32-bit) as the second argument of NULL or has some other defect.
>
> So, probably problem is with libsafe, not in glibc.

That would explain why it works on the 64 bit version, since libsafe  
is disabled there.

You can easily test this. Delete the file /etc/ld.so.preload.
Not sure if you have to bounce or not.

I would be open to completely removing libsafe from DL. It hasn't been  
updated in a decade...

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 13/02/2012 13:45, Heiko Zuerker wrote:
    <blockquote
cite="mid:201...@ww..."
      type="cite">
      <pre wrap="">Hey,


Quoting Andrzej Odyniec <a class="moz-txt-link-rfc2396E" href="mailto:an...@ma...">&lt;an...@ma...&gt;</a>:
</pre>
      <blockquote type="cite">
        <pre wrap="">Heiko Zuerker wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">The addition of cifsutils was in preparation of the upgrade to samba 3.6.
The new samba version doesn't include any of the cifs client tools, that's
why we need that package.
</pre>
        </blockquote>
        <pre wrap="">
Heiko,

You are right. I did not check carefully the cause. Now I'm wiser, because I
read the sources.

</pre>
        <blockquote type="cite">
          <pre wrap="">I just checked in the latest samba and an update to cifsutils. Hopefully the
newer version works better for you.
</pre>
        </blockquote>
        <pre wrap="">
Before I wrote first mail, I checked the same with these new  
versions of samba
and cifs-utils. It did not solve the problem. Anyway, thanks for the upgrade.

The problem is with realpath function, which is used in mount.cifs to
canonicalize mount point path. Two specifications are used for this function:
one assumes that the second argument is obvious pointer to the buffer for
canonicalized path, and the second allows to NULL pointer, when realpath
should malloc memory for that buffer. mount.cifs uses second form and gives
NULL pointer to this call, but for some reason (for me at least), realpath is
not accepting NULL in the second parameter and gives error. Well, only in
32-bit compilation. Maybe because of some additional packages, added myself,
cifs-utils catch invalid library? I have to find the cause or patch  
cifs-utils.
</pre>
      </blockquote>
      <pre wrap="">
Does the version I built work for you?

</pre>
    </blockquote>
    <br>
    Andrzej/Heiko:<br>
    <br>
    I wonder if this is related to the '<a
href="http://old.nabble.com/Samba-wide-links-problems%3A-canonicalize_connect_path-failed-td30728652.html">Samba
      wide links problems: canonicalize_connect_path failed</a>' problem
    that I reported on devil-linux-discuss on 21 Jan 2011 - and which
    still persists. It certainly sounds similar. Is it possible that the
    problem is caused by the location of smb.conf?<br>
  </body>
</html>

Quoting Dominic Raferd <dl...@ed...>:

> On 13/02/2012 13:45, Heiko Zuerker wrote:     > Hey,   Quoting Andrzej
> Odyniec <an...@ma...>[1]:> Heiko Zuerker wrote:> The addition of
> cifsutils was in preparation of the upgrade to samba 3.6. The new samba
> version doesn't include any of the cifs client tools, that's why we need
> that package.
>>> Heiko,  You are right. I did not check carefully the cause. Now I'm
>>> wiser, because I read the sources.> I just checked in the latest samba
>>> and an update to cifsutils. Hopefully the newer version works better
>>> for you.
>>> Before I wrote first mail, I checked the same with these new   versions
>>> of samba and cifs-utils. It did not solve the problem. Anyway, thanks
>>> for the upgrade.  The problem is with realpath function, which is used
>>> in mount.cifs to canonicalize mount point path. Two specifications are
>>> used for this function: one assumes that the second argument is obvious
>>> pointer to the buffer for canonicalized path, and the second allows to
>>> NULL pointer, when realpath should malloc memory for that buffer.
>>> mount.cifs uses second form and gives NULL pointer to this call, but
>>> for some reason (for me at least), realpath is not accepting NULL in
>>> the second parameter and gives error. Well, only in 32-bit compilation.
>>> Maybe because of some additional packages, added myself, cifs-utils
>>> catch invalid library? I have to find the cause or patch   cifs-utils.
>> Does the version I built work for you?
>
> Andrzej/Heiko:
>
> I wonder if this is related to the 'Samba       wide links problems:
> canonicalize_connect_path failed[2]' problem     that I reported on
> devil-linux-discuss on 21 Jan 2011 - and which     still persists. It
> certainly sounds similar. Is it possible that the     problem is caused by
> the location of smb.conf?

I was able to turn the wide links off when I upgraded to the latest DL  
with Samba 3.6.3.
Give that a try.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

On 13/02/2012 16:53, Heiko Zuerker wrote:
> I was able to turn the wide links off when I upgraded to the latest DL 
> with Samba 3.6.3. Give that a try. 

I look forward to it.  My Devil-Linux 1.6.0-RC2 has Samba 3.5.12. I 
guess 3.6.3 is coming in the next RC release?

Quoting Dominic Raferd <dl...@ed...>:

> On 13/02/2012 16:53, Heiko Zuerker wrote:
>> I was able to turn the wide links off when I upgraded to the latest DL
>> with Samba 3.6.3. Give that a try.
>
> I look forward to it.  My Devil-Linux 1.6.0-RC2 has Samba 3.5.12. I
> guess 3.6.3 is coming in the next RC release?

Yes it will be in RC3.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

Heiko Zuerker wrote:
> I just had another thought, maybe one of the glibc patches we're using is
> causing the issue.
> 
> You could try building with an empty glibc-patches directory.
> After the "make unpack", simply empty the directory before you do the "make
> all".

Hi Heiko,

Yes... I will try this too. But today I had some free time and added to the DL 
binutils and gdb. In this way I could see make.cifs inside . Well ... See for 
yourself:

> root@DesignerVM32:/var # gdb --args /sbin/mount.cifs //172.27.32.83/RAID /mnt
> GNU gdb (GDB) 7.4
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /sbin/mount.cifs...(no debugging symbols found)...done.
> (gdb) b realpath
> Breakpoint 1 at 0x17b8
> (gdb) run
> Starting program: /sbin/mount.cifs //172.27.32.83/RAID /mnt
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> 
> Breakpoint 1, 0xb7fdaec9 in realpath () from /lib/libsafe.so.2
> (gdb) q

As You can see, mount.cifs found realpath not in glibc but in libsafe (!).

> root@DesignerVM32:/var # objdump -t /lib/libsafe.so.2|grep realpath
> 0000501c l     O .bss   00000004              real_realpath.4419
> 00001ec0 g     F .text  00000154              realpath

Indeed, in libsafe library realpath function is present, perhaps safer because 
of protecting second argument from overflow, but probably not accepting (at 
least 32-bit) as the second argument of NULL or has some other defect.

So, probably problem is with libsafe, not in glibc.

Best regards

-- 
Andrzej Odyniec

Hi,

Heiko Zuerker wrote:
> That would explain why it works on the 64 bit version, since libsafe  
> is disabled there.
> 
> You can easily test this. Delete the file /etc/ld.so.preload.
> Not sure if you have to bounce or not.

Yes, I found it here: 
http://www.mail-archive.com/deb...@li.../msg310487.html
so, Dominic was right...

> I would be open to completely removing libsafe from DL. It hasn't been  
> updated in a decade...

As soon as I discovered that libsafe captures access to realpath, I turned off 
the libsafe from ld.so.preload and the problem disappeared. I started to 
wonder how to patch libsafe, but if you propose to remove, it may not worth to 
think about...

Best regards

-- 
Andrzej Odyniec

Quoting Andrzej Odyniec <an...@ma...>:
> Hi,
>
> Heiko Zuerker wrote:
>> That would explain why it works on the 64 bit version, since libsafe
>> is disabled there.
>>
>> You can easily test this. Delete the file /etc/ld.so.preload.
>> Not sure if you have to bounce or not.
>
> Yes, I found it here:
> http://www.mail-archive.com/deb...@li.../msg310487.html
> so, Dominic was right...
>
>> I would be open to completely removing libsafe from DL. It hasn't been
>> updated in a decade...
>
> As soon as I discovered that libsafe captures access to realpath, I  
> turned off
> the libsafe from ld.so.preload and the problem disappeared. I started to
> wonder how to patch libsafe, but if you propose to remove, it may  
> not worth to
> think about...

I removed libsafe from CVS and added code to upgrade-config to remove  
the specific line from /etc/ld.so.preload
The changes are untested, please let me know if they work (especially  
the upgrade-config)

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

On 21/02/2012 21:57, Heiko Zuerker wrote:
> Quoting Andrzej Odyniec<an...@ma...>:
>> Hi,
>>
>> Heiko Zuerker wrote:
>>> That would explain why it works on the 64 bit version, since libsafe
>>> is disabled there.
>>>
>>> You can easily test this. Delete the file /etc/ld.so.preload.
>>> Not sure if you have to bounce or not.
>> Yes, I found it here:
>> http://www.mail-archive.com/deb...@li.../msg310487.html
>> so, Dominic was right...
>>
>>> I would be open to completely removing libsafe from DL. It hasn't been
>>> updated in a decade...
>> As soon as I discovered that libsafe captures access to realpath, I
>> turned off
>> the libsafe from ld.so.preload and the problem disappeared. I started to
>> wonder how to patch libsafe, but if you propose to remove, it may
>> not worth to
>> think about...
> I removed libsafe from CVS and added code to upgrade-config to remove
> the specific line from /etc/ld.so.preload
> The changes are untested, please let me know if they work (especially
> the upgrade-config)
>

Please see my suggestion in Mantis. The good news is that with this line 
taken out of /etc/ld.so.preload and samba restarted, the problem 
requiring 'wide links=yes' is gone in 1.6.0-RC2 32 bit.

Quoting Dominic Raferd <dl...@ed...>:

> On 21/02/2012 21:57, Heiko Zuerker wrote:
>> Quoting Andrzej Odyniec<an...@ma...>:
>>> Hi,
>>>
>>> Heiko Zuerker wrote:
>>>> That would explain why it works on the 64 bit version, since libsafe
>>>> is disabled there.
>>>>
>>>> You can easily test this. Delete the file /etc/ld.so.preload.
>>>> Not sure if you have to bounce or not.
>>> Yes, I found it here:
>>> http://www.mail-archive.com/deb...@li.../msg310487.html
>>> so, Dominic was right...
>>>
>>>> I would be open to completely removing libsafe from DL. It hasn't been
>>>> updated in a decade...
>>> As soon as I discovered that libsafe captures access to realpath, I
>>> turned off
>>> the libsafe from ld.so.preload and the problem disappeared. I started to
>>> wonder how to patch libsafe, but if you propose to remove, it may
>>> not worth to
>>> think about...
>> I removed libsafe from CVS and added code to upgrade-config to remove
>> the specific line from /etc/ld.so.preload
>> The changes are untested, please let me know if they work (especially
>> the upgrade-config)
>>
>
> Please see my suggestion in Mantis. The good news is that with this line
> taken out of /etc/ld.so.preload and samba restarted, the problem
> requiring 'wide links=yes' is gone in 1.6.0-RC2 32 bit.

Nice!

I changed the code as proposed.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

On 22/02/2012 13:49, Heiko Zuerker wrote:
> Quoting Dominic Raferd<dl...@ed...>:
>
>> On 21/02/2012 21:57, Heiko Zuerker wrote:
>>> Quoting Andrzej Odyniec<an...@ma...>:
>>>> Hi,
>>>>
>>>> Heiko Zuerker wrote:
>>>>> That would explain why it works on the 64 bit version, since libsafe
>>>>> is disabled there.
>>>>>
>>>>> You can easily test this. Delete the file /etc/ld.so.preload.
>>>>> Not sure if you have to bounce or not.
>>>> Yes, I found it here:
>>>> http://www.mail-archive.com/deb...@li.../msg310487.html
>>>> so, Dominic was right...
>>>>
>>>>> I would be open to completely removing libsafe from DL. It hasn't been
>>>>> updated in a decade...
>>>> As soon as I discovered that libsafe captures access to realpath, I
>>>> turned off
>>>> the libsafe from ld.so.preload and the problem disappeared. I started to
>>>> wonder how to patch libsafe, but if you propose to remove, it may
>>>> not worth to
>>>> think about...
>>> I removed libsafe from CVS and added code to upgrade-config to remove
>>> the specific line from /etc/ld.so.preload
>>> The changes are untested, please let me know if they work (especially
>>> the upgrade-config)
>>>
>> Please see my suggestion in Mantis. The good news is that with this line
>> taken out of /etc/ld.so.preload and samba restarted, the problem
>> requiring 'wide links=yes' is gone in 1.6.0-RC2 32 bit.
> Nice!
>
> I changed the code as proposed.
>

It's good to have got this bug. Great catch Andrzej :-)