Bug 573246

Suresh, please take a look.

Thanks for the bug report.

I'll take a look but only after finishing high priority items.

Do you use IP address to mount or hostname? If you're using IP, could you try with hostname and check?

Sorry for the late answer, but I did not get an information per email about your comment.
The problem initially occurred using pam_mount. pam_mount was configured for using server's hostname (but not fully qualified). After that I checked the issue without using pam_mount, doing a cifs mount directly on console. I do not exactly remember if this was with IP or hostname, but I think hostname. Result was the same, as described above. Before, with OpenSuSE 11.1 and identical server configuration, there was no such problem.
If needed, I can verify this weekend if using server's hostname or IP makes any difference.
BTW: On server side, I use dhcpd with dynamic update of DNS (bind9).

Yes, please. That would help isolating the issue to some extent..

So, tested it. It doesn't matter if i use IP or hostname:

fliewatuet:/var/log # mount -t cifs //lilienthal/Austausch /Srv_Austausch -o user=rmueller
Password:
fliewatuet:/var/log # mount -t cifs //192.168.99.5/Ablage_DR /Srv_Ablage_DR -o user=rmueller
Password:

fliewatuet:/ # df -h
Dateisystem          GröÃe Benut  Verf Ben% Eingehängt auf
/dev/sda6              20G  6,3G   13G  34% /
udev                  3,0G  260K  3,0G   1% /dev
/dev/sda1              97M   31M   62M  34% /boot
lilienthal.example.com:/home/serverbased/rmueller
                       55G  7,4G   45G  15% /home/serverbased/rmueller
//lilienthal/Austausch
                      373G  195G  178G  53% /Srv_Austausch
//192.168.99.5/Ablage_DR
                      373G  195G  178G  53% /Srv_Ablage_DR

Now the renew of the lease happens (/var/log/messages):

Feb 24 12:45:37 fliewatuet dhcpcd[2440]: eth1: renewing lease of 192.168.99.90
Feb 24 12:45:37 fliewatuet dhcpcd[2440]: eth1: leased 192.168.99.90 for 3000 seconds
Feb 24 12:45:37 fliewatuet dhcpcd[2440]: eth1: adding IP address 192.168.99.90/24
Feb 24 12:45:37 fliewatuet dhcpcd[2440]: eth1: adding default route via 192.168.99.254 metric 0
Feb 24 12:45:37 fliewatuet ifup:     eth1      device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

and then:

fliewatuet:/ # date
Mi 24. Feb 12:49:39 CET 2010

fliewatuet:/ # df -h
Dateisystem          GröÃe Benut  Verf Ben% Eingehängt auf
/dev/sda6              20G  6,3G   13G  34% /
udev                  3,0G  260K  3,0G   1% /dev
/dev/sda1              97M   31M   62M  34% /boot


Interesting to me: The autofs NFS-mounted home-directory also disappears when it's not used. This time I tested from remote via ssh (root), so no idea why the homedir was mounted at bootup without any user logged in. Normally I didn't recognize that because I'm always logged in. Maybe a dhclient issue?

Yes, mat be a dhclient issue.. I just tested on my 11.2 box with short lease-time and the mount didn't disappear.

Could you please test on a older version of dhclient/dhcpd?

OK, I have 5 boxes connected to 2 different servers (3 in my office, 2 at home) showing immediately this issue after a fresh install of SuSE 11.2. All machines have had SuSE 11.1 / 10.3 before, without this problem. One server is an old SuSE 9.3 box, an therefore also an very old dhcpd, the other one is a Debian 5 with dhcp3-server package used.
So I don't think it's an issue of dhcpd.

Yesterday I noticed, that SuSE 11.2 installs both dhcpcd and dhclient package, and preferably uses dhcpcd, when nothing is configured in /etc/sysconfig/network/dhcp for the client binary. Now I changed this config to "dhclient", and the issue has gone. All mounts now survive an IP renewal.

So it seems to be an dhcpcd related problem......

How can I test an older package of dhcpcd on SuSE 11.2 (if I should)? Is there any rpm-package which will work? 

Cheers,
Robert

Are you using '-p' (persistent option) with dhcpcd. There was a known bug bnc#551376 that fixed a problem of '-p' option being not honoured. This fix is present in dhcpcd-3.2.3 and greater.

Update your dhcpcd and try with '-p' option. If you still have the problem wth dhcpcd, I'll reassign this bug appropriately. Thanks!

I'm unable to reproduce the issue with the new updated dhcpcd. Please update your dhcpcd package.

Please reopen this bug should you see the problem after updating. Thanks!

Hi all,

my system is also suffering from this bug. I've found out that the following happens on each renewal of the dhcp lease:

dhcpcd
  --> /etc/sysconfig/network/scripts/dhcpcd-hook [..] up
    --> if-up br0 -o dhcp
      --> if-up.d/21-smbfs
        --> /usr/sbin/rcsmbfs restart
          --> umount -at cifs

The command "/usr/sbin/rcsmbfs restart" will unmount all cifs shares and only remount those shares which are listed in /etc/samba/smbfstab. If shares are not present here (for instance in case of mounting manually or using pam_mount), it will not be mounted again.

Independent of the fact that only shares present in /etc/samba/smbfstab are remounted, I disbelieve that it's a good behavior to remount a device every few minutes...

regards
Christian

Hi,

for me the issue was immediately solved after I added the "-p" option to dhcpcd options in /etc/sysconfig/network/dhcp. For miscellaneous reasons this option seems not to be default anymore. Up to 11.1 this was probably the case. Up to this problem, I never spent time understanding what dhcp-client software does in detail - it always simply worked ;-)

Hope that helps,

Robert

There was a known bug in dhcpcd as mentioned in Comment #9. Please upgrade your dhcpcd version and try to use '-p' option and update whether the issue is still reproducible.

(In reply to comment #9)
> There was a known bug bnc#551376 that fixed a problem of '-p' option being not 
> honoured. This fix is present in dhcpcd-3.2.3 and greater.
openSUSE 11.2 is already shipped with dhcpcd-3.2.3-47.2. I'm using the latest version from openSUSE 11.2 updates (dhcpcd-3.2.3-47.4.1).

(In reply to comment #13)
> There was a known bug in dhcpcd as mentioned in Comment #9. Please upgrade your
> dhcpcd version and try to use '-p' option and update whether the issue is still
> reproducible.

I've entered the -p option to DHCPCD_USER_OPTIONS in 
/etc/sysconfig/network/dhcp and rebooted the system. I cannot see any difference, the script "/etc/sysconfig/network/scripts/dhcpcd-hook [...] up" is still called every 5 minutes which in turn umounts all cifs shares.

I cannot see that there might be anything wrong with dhcpcd (or its configuration). For me it seems to be obvious that either the call to "rcsmbfs restart" (in if-up.d/21-smbfs) should be changed, or rcsmbfs had to be reworked, that a stop/restart only umounts shares originally present in smbfstab. (but the latter would also be a poor solution because then some shares would be periodically remounted every few minutes)

regards
Christian

(In reply to comment #14)

> I cannot see that there might be anything wrong with dhcpcd (or its
> configuration). For me it seems to be obvious that either the call to "rcsmbfs
> restart" (in if-up.d/21-smbfs) should be changed, or rcsmbfs had to be
> reworked, that a stop/restart only umounts shares originally present in
> smbfstab. (but the latter would also be a poor solution because then some
> shares would be periodically remounted every few minutes)
> 

This bug was not reproducible in my setup with dhclient and that is why I'm thinking this is a dhcpcd issue. Could you see whether it is reproducible when you use dhclient instead of dhcpcd?

Also I think this is nothing specific to cifs; any network filesystem should have the same behavior (for e.g. nfs mounts).

(In reply to comment #15)

> This bug was not reproducible in my setup with dhclient and that is why I'm
> thinking this is a dhcpcd issue. Could you see whether it is reproducible when
> you use dhclient instead of dhcpcd?

It's not surprising that the problem doesn't exist with dhclient. With dhcpcd a complex script (/etc/sysconfig/network/scripts/dhcpcd-hook) is called periodically every time the lease is renewed. dhclient uses a completely different script (/sbin/dhclient-script) which is only called once after dhclient initially gets the lease.


dhclient (at startup):
----------------------
ifup br0
  --> ifup-dhcp br0
    --> /sbin/dhclient
       --> /sbin/dhclient-script


dhclient (at lease renewal):
----------------------
/sbin/dhclient
  <nothing>


dhcpcd (at startup):
--------------------
ifup br0
  --> ifup-dhcp br0
    --> /sbin/dhcpcd
      --> /etc/sysconfig/network/scripts/dhcpcd-hook
        --> ifdown br0 -o dhcp
        --> ifup br0 -o dhcp
          --> if-up.d/21-smbfs
            --> rcsmbfs restart


dhcpcd (at lease renewal):
--------------------------
/sbin/dhcpcd
  --> /etc/sysconfig/network/scripts/dhcpcd-hook
    --> ifup br0 -o dhcp
      --> if-up.d/21-smbfs
        --> rcsmbfs restart


> Also I think this is nothing specific to cifs; any network filesystem should
> have the same behavior (for e.g. nfs mounts).

I don't know why the package "samba-client" places a script into /etc/sysconfig/network/if-up.d/ and the package "nfs-client" doesn't.


Using dhclient instead of dhcpcd is no solution for me. Why not fixing the configuration for dhcpcd?

regards
Christian

This bug most likely due to dhcpcd. Please reassign this appropriately.

I also have this problem.

If I run the command
  mount -t cifs //server/share /mnt/mountpoint
the share gets mounted and it becomes present in in /etc/mtab

When the dhcp lease is renewed the script 
  "/etc/sysconfig/network/if-up.d/21-smbfs" 
is run which in turn calls /usr/sbin/rcsmbfs restart

The rcsmbfs script runs the command 
  "umount -at cifs"
which will unmount all cifs mounts that are present in the mtab file.

A workaround for this is to mount your cifs shares with
  mount -n -t cifs //server/share /mnt/mountpoint
which will not put a line into the mtab file.

This is however a workaround that should not be needed.

PS. I use dhcpcd 3.2.3-47.4.1

Best Regards Gustav

*** Bug 604097 has been marked as a duplicate of this bug. ***

Just an update. I have also tried the -p option for dhcpcd now. It does not make any difference, the cifs shares that are mounted from the command line still disappears.
The dhcpcd version is 3.2.3-47.4.1

(In reply to comment #16)
> (In reply to comment #15)
> 
> > This bug was not reproducible in my setup with dhclient and that is why I'm
> > thinking this is a dhcpcd issue. Could you see whether it is reproducible when
> > you use dhclient instead of dhcpcd?
> 
> It's not surprising that the problem doesn't exist with dhclient. With dhcpcd a
> complex script (/etc/sysconfig/network/scripts/dhcpcd-hook) is called
> periodically every time the lease is renewed. dhclient uses a completely
> different script (/sbin/dhclient-script) which is only called once after
> dhclient initially gets the lease.
> 
> 
> dhclient (at startup):
> ----------------------
> ifup br0
>   --> ifup-dhcp br0
>     --> /sbin/dhclient
>        --> /sbin/dhclient-script
> 
> 
> dhclient (at lease renewal):
> ----------------------
> /sbin/dhclient
>   <nothing>
> 
> 
> dhcpcd (at startup):
> --------------------
> ifup br0
>   --> ifup-dhcp br0
>     --> /sbin/dhcpcd
>       --> /etc/sysconfig/network/scripts/dhcpcd-hook
>         --> ifdown br0 -o dhcp
>         --> ifup br0 -o dhcp
>           --> if-up.d/21-smbfs
>             --> rcsmbfs restart
> 
> 
> dhcpcd (at lease renewal):
> --------------------------
> /sbin/dhcpcd
>   --> /etc/sysconfig/network/scripts/dhcpcd-hook
>     --> ifup br0 -o dhcp
>       --> if-up.d/21-smbfs
>         --> rcsmbfs restart

I'd say it is a broken 21-smbfs script, that ignores the -o dhcp options
and restarts the smb/nmb on every "up" ("up ; up ; up" without a "down"
between) without any reason / check.

Note also: "new" arg to dhcpcd-hook != "dhcp renew":

- "new" argument in dhcpcd-hook (dhcpcd --script interface) does
   not mean "renew" as the name may suggest.
   it means: new IP address
   => restart everything; the dhcpcd-hook calls
      "ifdown $iface -o dhcp ; ifup $iface -o dhcp"
   then.

- "up" argument in dhcpcd-hook means, IP didn't changed changed since
  last reboot (==dhcp reboot state) and the interface configuration
  finished. that is, "up" basically means "renew".
  => just signal post-scripts that we are "up" now via "ifup -o dhcp".

  We've added an additional "complete" action to dhcpcd/dhcpcd-hook
  that is called after "up" and "new" and signals, that at this point
  really all configuration steps are complete, e.g. also the hostname
  is up-to-date. The "ifup $iface -o dhcp" is called in complete now.

  The difference is dhcpcd<->dhcpcd-hook internal:
  - before:
          up:  ... ifup $iface -o dhcp
         new:  ... ifdown $iface -o dhcp ; ifup $iface -o dhcp
  - current:
          up:  ...
         new:  ... ifdown $iface -o dhcp
    complete:      ifup $iface -o dhcp

Note also, that dhclient[-script] was not 100% integrated here and
didn't executed any ifup / ifdown -o dhcp actions (that is if-up.d
or ifservice scripts) until now. This has been completed/fixed in
factory.

BTW: See also "man 5 ifservices".

(In reply to comment #8)
> OK, I have 5 boxes connected to 2 different servers (3 in my office, 2 at home)
> showing immediately this issue after a fresh install of SuSE 11.2. All machines
> have had SuSE 11.1 / 10.3 before, without this problem. One server is an old
> SuSE 9.3 box, an therefore also an very old dhcpd, the other one is a Debian 5
> with dhcp3-server package used.

OK, thins means it changed between 11.1 and 11.2, right?

> So I don't think it's an issue of dhcpd.
> 
> Yesterday I noticed, that SuSE 11.2 installs both dhcpcd and dhclient package,
> and preferably uses dhcpcd, when nothing is configured in
> /etc/sysconfig/network/dhcp for the client binary. Now I changed this config to
> "dhclient", and the issue has gone. All mounts now survive an IP renewal.
> 
> So it seems to be an dhcpcd related problem......

No. It is missed integration of the dhclient[-script] :-)

But IMO the reason for the problem is the restart in 21-smbfs without any
reason / check, except that /etc/init.d/smb and nmb scripts are active.

This causes that when the system boots up, there is
   /etc/init.d/smb start
and on _every_ "up" of an interface, 21-smbfs makes
   /etc/init.d/smb restart

(In reply to comment #22)
> OK, thins means it changed between 11.1 and 11.2, right?

Ack

Could you eventually solve this problem until release of 11.3?

regards
Christian

(In reply to comment #22)
> (In reply to comment #8)
> > OK, I have 5 boxes connected to 2 different servers (3 in my office, 2 at home)
> > showing immediately this issue after a fresh install of SuSE 11.2. All machines
> > have had SuSE 11.1 / 10.3 before, without this problem. One server is an old
> > SuSE 9.3 box, an therefore also an very old dhcpd, the other one is a Debian 5
> > with dhcp3-server package used.
> 
> OK, thins means it changed between 11.1 and 11.2, right?
> 
> > So I don't think it's an issue of dhcpd.
> > 
> > Yesterday I noticed, that SuSE 11.2 installs both dhcpcd and dhclient package,
> > and preferably uses dhcpcd, when nothing is configured in
> > /etc/sysconfig/network/dhcp for the client binary. Now I changed this config to
> > "dhclient", and the issue has gone. All mounts now survive an IP renewal.
> > 
> > So it seems to be an dhcpcd related problem......
> 
> No. It is missed integration of the dhclient[-script] :-)
> 
> But IMO the reason for the problem is the restart in 21-smbfs without any
> reason / check, except that /etc/init.d/smb and nmb scripts are active.
> 
> This causes that when the system boots up, there is
>    /etc/init.d/smb start
> and on _every_ "up" of an interface, 21-smbfs makes
>    /etc/init.d/smb restart

Lars: Do you remember any change between 11.1 and 11.2 which would have caused the above? I don't remember making any changes to the smb startup script.

There is no diff between the init script of 11.1 (3.2.7) and 11.2 (3.4.3).

(In reply to comment #22)
> (In reply to comment #8)
> 
> OK, thins means it changed between 11.1 and 11.2, right?
> 
> > So I don't think it's an issue of dhcpd.
> > 
> > Yesterday I noticed, that SuSE 11.2 installs both dhcpcd and dhclient package,
> > and preferably uses dhcpcd, when nothing is configured in
> > /etc/sysconfig/network/dhcp for the client binary. Now I changed this config to
> > "dhclient", and the issue has gone. All mounts now survive an IP renewal.
> > 
> > So it seems to be an dhcpcd related problem......
> 
> No. It is missed integration of the dhclient[-script] :-)
> 
> But IMO the reason for the problem is the restart in 21-smbfs without any
> reason / check, except that /etc/init.d/smb and nmb scripts are active.
> 
> This causes that when the system boots up, there is
>    /etc/init.d/smb start
> and on _every_ "up" of an interface, 21-smbfs makes
>    /etc/init.d/smb restart

There is no change between 11.1 and 11.2 in smb init script. If this is the issue, how come it didn't appear in 11.1 and earlier? Has something changed  in Network manager or dhcpcd..?

If it is due to some other changes, then it is a regression caused by that component and not smb/cifs, right?

(In reply to comment #27)
> (In reply to comment #22)
> > (In reply to comment #8)
> > 
> > > So it seems to be an dhcpcd related problem......
> > 
> > No. It is missed integration of the dhclient[-script] :-)
> > 
> > But IMO the reason for the problem is the restart in 21-smbfs without any
> > reason / check, except that /etc/init.d/smb and nmb scripts are active.
> > 
> > This causes that when the system boots up, there is
> >    /etc/init.d/smb start
> > and on _every_ "up" of an interface, 21-smbfs makes
> >    /etc/init.d/smb restart
> 
> There is no change between 11.1 and 11.2 in smb init script. If this is the
> issue, how come it didn't appear in 11.1 and earlier? Has something changed  in
> Network manager or dhcpcd..?
> 
> If it is due to some other changes, then it is a regression caused by that
> component and not smb/cifs, right?

No, it isn't a regression in sysconfig. It is an incorrect 21-smbfs script.
I _guess_ the umounts just failed before and didn't caused any problem.

The dhcpcd hook on SLE-10 and I think already on SLES-9 also called the
if-up.d scripts -- the ifup man page documents this. SuSEfirewall2 using
the if-up.d interface would not refresh its rules without these calls.

Marius: Thanks for the explanation.

Now that I spend more time on this, I seem to understand what is going and what we should be doing.

I think the reason behind 21-smbfs or 21-cifs (in 11.3) restarting rccifs when the lease is renewed because the IPaddress could possibly change. However, it should not never drop the existing mounts.

I think we could possibly check whether the IPaddress remains the same or not and restart rccifs only if it changes.

Looks like if we are able to get the 'state' value from /etc/sysconfig/network/scripts/dhcpcd-hook, then we could check if 'state' is 'new' and not 'up' and restart the rccifs script.

Marius, Lars, any idea whether it is possible to pass this 'state' value down to 21-cifs script?

(In reply to comment #29)
> I think the reason behind 21-smbfs or 21-cifs (in 11.3) restarting rccifs
> when the lease is renewed because the IPaddress could possibly change.

Yes, I think also this was the reason for.

> However, it should not never drop the existing mounts.

Well, when the old IP went away (or more worse: e.g. the network changed)
it is required to remount I think...


(In reply to comment #30)
> Looks like if we are able to get the 'state' value from
> /etc/sysconfig/network/scripts/dhcpcd-hook, then we could check if 'state' is
> 'new' and not 'up' and restart the rccifs script.
> 
> Marius, Lars, any idea whether it is possible to pass this 'state' value down
> to 21-cifs script?

You can read it with:

. /etc/sysconfig/network/scripts/functions
state=`read_cached_config_data dhcp4_state "$interface"`

or also like this:

state=`{ . /etc/sysconfig/network/scripts/functions && \
         read_cached_config_data dhcp4_state "$interface" ; } 2>/dev/null`

Created attachment 374259 [details]
Proposed patch

Could you patch /etc/sysconfig/network/if-up.d/21-cifs (preferably backup original file) with the changes attached and see whether it resolves the problem for you?

Created attachment 374482 [details]
Modified patch for openSUSE 11.2

(In reply to comment #32)
> Created an attachment (id=374259) [details]
> Proposed patch
> 
> Could you patch /etc/sysconfig/network/if-up.d/21-cifs (preferably backup
> original file) with the changes attached and see whether it resolves the
> problem for you?

On 11.2, the file name is /etc/sysconfig/network/if-up.d/21-smbfs. Instead of patching the symlink I've created a patch for the target file (/etc/sysconfig/network/scripts/smbfs). Please note my change in the "if" condition, your syntax might be wrong:

your
if "$state" == "new"

mine
if [ "$state" = "new" ]

Altogether the patch seems to work, my cifs mounts are not disconnected anymore. 

Additionally you might think about only unmounting shared listed in smbfstab instead of using "umount -at cifs"

Created attachment 378796 [details]
Patch for 11.3

Thanks Christian!

Here is the updated patch for openSUSE-11.3. openSUSE-11.2 could use patch from Comment #34.

Lars: This patch for /etc/sysconfig/network/scripts/cifs{smbfs} file which is part of samba-client package is attached (for both 11.2 and 11.3). I am not sure about how to commit this patch and who will take care of committing this to the repo?

For oS 11.2 please merge it to the 3.4.3 branches.

For oS 11.3 it's 3.5.4 which is in trunk at the moment.

For the package change log please use a short (if possible keep it in the borders of one or two 78 char lines) but meaningful sentence.  Then it's easier to reuse the same content by the maintenance team as soon as we have to release an update.

Regarding the suggestion in comment #34 'Additionally you might think about only unmounting shared listed in smbfstab instead of using "umount -at cifs"' I'm not sure which issues are addressed by this approach or if this might cause new.

Fix committed to 11.2 and 11.3. Marking this as Resolved Fixed.

Update released for: cifs-mount, cifs-mount-debuginfo, ldapsmb, libnetapi-devel, libnetapi0, libnetapi0-debuginfo, libsmbclient-devel, libsmbclient0, libsmbclient0-debuginfo, libsmbsharemodes-devel, libsmbsharemodes0, libsmbsharemodes0-debuginfo, libtalloc-devel, libtalloc1, libtalloc1-debuginfo, libtdb-devel, libtdb1, libtdb1-debuginfo, libwbclient-devel, libwbclient0, libwbclient0-debuginfo, samba, samba-client, samba-client-debuginfo, samba-debuginfo, samba-debugsource, samba-devel, samba-doc, samba-krb-printing, samba-krb-printing-debuginfo, samba-winbind, samba-winbind-debuginfo
Products:
openSUSE 11.2 (debug, i586, x86_64)

Update released for: ldapsmb, libldb-devel, libldb0, libldb0-debuginfo, libnetapi-devel, libnetapi0, libnetapi0-debuginfo, libsmbclient-devel, libsmbclient0, libsmbclient0-debuginfo, libsmbsharemodes-devel, libsmbsharemodes0, libsmbsharemodes0-debuginfo, libtalloc-devel, libtalloc2, libtalloc2-debuginfo, libtdb-devel, libtdb1, libtdb1-debuginfo, libtevent-devel, libtevent0, libtevent0-debuginfo, libwbclient-devel, libwbclient0, libwbclient0-debuginfo, samba, samba-client, samba-client-debuginfo, samba-debuginfo, samba-debugsource, samba-devel, samba-doc, samba-krb-printing, samba-krb-printing-debuginfo, samba-winbind, samba-winbind-debuginfo
Products:
openSUSE 11.3 (debug, i586, x86_64)

Update released for: cifs-mount, ldapsmb, libnetapi-devel, libnetapi0, libsmbclient-devel, libsmbclient0, libsmbclient0-32bit, libsmbclient0-x86, libsmbsharemodes-devel, libsmbsharemodes0, libtalloc-devel, libtalloc1, libtalloc1-32bit, libtalloc1-x86, libtdb-devel, libtdb1, libtdb1-32bit, libtdb1-x86, libwbclient-devel, libwbclient0, libwbclient0-32bit, libwbclient0-x86, samba, samba-32bit, samba-client, samba-client-32bit, samba-client-x86, samba-debuginfo, samba-debuginfo-32bit, samba-debuginfo-x86, samba-debugsource, samba-devel, samba-krb-printing, samba-vscan, samba-winbind, samba-winbind-32bit, samba-winbind-x86, samba-x86
Products:
SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP1 (i386, x86_64)
SLE-SDK 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP1 (i386, x86_64)

The SWAMPID for this issue is 52409.
This issue was rated as low.
Please submit fixed packages until 2013-06-06.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/52409

Update released for: cifs-mount, ldapsmb, libmsrpc, libmsrpc-devel, libsmbclient, libsmbclient-32bit, libsmbclient-64bit, libsmbclient-devel, libsmbclient-x86, libsmbsharemodes, libsmbsharemodes-devel, samba, samba-32bit, samba-64bit, samba-client, samba-client-32bit, samba-client-64bit, samba-client-x86, samba-debuginfo, samba-krb-printing, samba-python, samba-vscan, samba-winbind, samba-winbind-32bit, samba-winbind-64bit, samba-winbind-x86, samba-x86
Products:
SLE-DESKTOP 10-SP4 (i386, x86_64)
SLE-SDK 10-SP4 (i386, ia64, ppc, s390x, x86_64)
SLE-SERVER 10-SP4 (i386, ia64, ppc, s390x, x86_64)

This is an autogenerated message for OBS integration:
This bug (573246) was mentioned in
https://build.opensuse.org/request/show/48115 11.2:Test / samba
https://build.opensuse.org/request/show/48116 11.3:Test / samba