I have not looked into recent Jenkins changes, but as this plugin has not changed for a very long time, I think that something has been broken in core.

This will need investigation in Jenkins core.

This looks to me like an incompatibility introduced in core that will require an update in Publish over CIFS. I'm not familiar with the achitecture though. I did see a similar issue related to this in JIRA from 2011, where CIFS would only persist the first share. I don't know if it's truly related. Thanks.

My apologies - didn't notice the linked issue. I'll defer to people who know Jenkins.

Is anyone looking at this? This is a significant issue. Below is the log output.

Mar 20, 2013 7:58:57 AM hudson.model.Descriptor load
WARNING: Failed to load /home/jenkins/jenkins.plugins.publish_over_cifs.CifsPublisherPlugin.xml
hudson.util.IOException2: Unable to read /home/jenkins/jenkins.plugins.publish_over_cifs.CifsPublisherPlugin.xml
at hudson.XmlFile.unmarshal(XmlFile.java:170)
at hudson.model.Descriptor.load(Descriptor.java:806)
at jenkins.plugins.publish_over.BPPluginDescriptor.<init>(BPPluginDescriptor.java:56)
at jenkins.plugins.publish_over_cifs.CifsPublisherPlugin$Descriptor.<init>(CifsPublisherPlugin.java:100)
at jenkins.plugins.publish_over_cifs.CifsPublisherPlugin$Descriptor$$FastClassByGuice$$9d63b4dd.newInstance(<generated>)
at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:108)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:259)
at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:59)
at hudson.ExtensionFinder$GuiceFinder$4$1.get(ExtensionFinder.java:422)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:391)
at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:382)
at hudson.ExtensionFinder._find(ExtensionFinder.java:151)
at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:318)
at hudson.ExtensionList.load(ExtensionList.java:295)
at hudson.ExtensionList.ensureLoaded(ExtensionList.java:248)
at hudson.ExtensionList.iterator(ExtensionList.java:138)
at jenkins.model.Jenkins.getDescriptorByType(Jenkins.java:1175)
at hudson.plugins.copyartifact.BuildSelectorParameter.initAliases(BuildSelectorParameter.java:100)
at hudson.plugins.copyartifact.CopyArtifactPlugin.postInitialize(CopyArtifactPlugin.java:35)
at hudson.PluginManager$2$1$2.run(PluginManager.java:352)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at jenkins.model.Jenkins$7.runTask(Jenkins.java:887)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
Caused by: com.thoughtworks.xstream.converters.ConversionException: java.lang.ClassCastException@551563a2 : java.lang.ClassCastException@551563a2
---- Debugging information ----
message : java.lang.ClassCastException@551563a2
cause-exception : java.lang.IllegalArgumentException
cause-message : java.lang.ClassCastException@551563a2
class : jenkins.plugins.publish_over_cifs.CifsHostConfiguration
required-type : jenkins.plugins.publish_over_cifs.CifsHostConfiguration
converter-type : hudson.util.RobustReflectionConverter
path : /jenkins.plugins.publish_over_cifs.CifsPublisherPlugin$Descriptor/hostConfigurations/jenkins.plugins.publish_over_cifs.CifsHostConfiguration
line number : 14
class[1] : hudson.util.CopyOnWriteList
converter-type[1] : hudson.util.XStream2$AssociatedConverterImpl
class[2] : jenkins.plugins.publish_over_cifs.CifsPublisherPlugin$Descriptor
version : null
-------------------------------
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:79)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71)
at hudson.util.CopyOnWriteList$ConverterImpl.unmarshal(CopyOnWriteList.java:193)
at hudson.util.CopyOnWriteList$ConverterImpl.unmarshal(CopyOnWriteList.java:172)
at hudson.util.XStream2$AssociatedConverterImpl.unmarshal(XStream2.java:337)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:333)
at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:275)
at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:222)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)
at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:134)
at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1061)
at hudson.util.XStream2.unmarshal(XStream2.java:109)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1045)
at hudson.XmlFile.unmarshal(XmlFile.java:166)
... 37 more
Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException@551563a2
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callReadResolve(SerializationMethodInvoker.java:66)
at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:223)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
... 60 more

For what it's worth, I also use Publish Over SSH, with many connections configured, and they all load just fine. The only real difference between the two in the xml file are the lines:

<msg class="jenkins.plugins.publish_over_cifs.CifsPublisherPlugin$DescriptorMessages"/>
<hostConfigClass>jenkins.plugins.publish_over_cifs.CifsHostConfiguration</hostConfigClass>

And removing these does not help. This leads me to believe that it's something about the Cifs plugin that is preventing the load from working (since the SSH configurations load fine).

Kevin, I had a brief look at the po-ssh and po-ftp last weekend, and was unable to reproduce the issues that people are facing.

I am fairly certain that the problem is due to the xstream update in 1.504, so downgrading to 1.503 should fix your issues.

There is definitely a problem, but it is obviously not deterministic, and may be down to the time taken to render the configuration page (maybe not complete before the form is submitted) - but this is just a total guess based on the stack traces that have been submitted and my inability to reproduce the problem when upgrading Jenkins to 1.504.

I guess another possibility may be some other change in Jenkins or another plugin which is affecting the rendering of the configuration page.

Can you post a list of your installed plugins and their versions?

bap,

My jenkins.log startup is below. The error reading the cifs configuration appears long before jenkins even becomes available for login, so, I do not think it's related to the configuration page.

It would take me a while to obtain a list of plugins, as there are quite a few. I did just remove a bunch of unused plugins, but this did not change the situation. I'll attach a list of the plugins below (without versions – they are all current.)

INFO: Beginning extraction from war file
Jenkins home directory: /home/jenkins found at: System.getProperty("JENKINS_HOME")
Mar 21, 2013 11:47:29 AM winstone.Logger logInternal
INFO: HTTP Listener started: port=8080
Mar 21, 2013 11:47:29 AM winstone.Logger logInternal
INFO: AJP13 Listener started: port=8009
Mar 21, 2013 11:47:29 AM winstone.Logger logInternal
INFO: Winstone Servlet Engine v0.9.10 running: controlPort=disabled
Mar 21, 2013 11:47:30 AM jenkins.InitReactorRunner$1 onAttained
INFO: Started initialization
Mar 21, 2013 11:47:30 AM jenkins.InitReactorRunner$1 onAttained
INFO: Listed all plugins
Mar 21, 2013 11:47:30 AM com.sonyericsson.hudson.plugins.gerrit.trigger.PluginImpl start
INFO: Starting
Mar 21, 2013 11:47:30 AM com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritSendCommandQueue startQueue
INFO: SendQueue started! Current pool size: 1
Mar 21, 2013 11:47:30 AM com.sonyericsson.hudson.plugins.gerrit.trigger.PluginImpl start
INFO: Started
Mar 21, 2013 11:47:30 AM com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Starting Up...
Mar 21, 2013 11:47:30 AM hudson.plugins.greenballs.PluginImpl start
INFO: Green Balls!
Mar 21, 2013 11:47:30 AM jenkins.InitReactorRunner$1 onAttained
INFO: Prepared all plugins
Mar 21, 2013 11:47:30 AM com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit
Mar 21, 2013 11:47:35 AM hudson.model.Descriptor load
WARNING: Failed to load /home/jenkins/jenkins.plugins.publish_over_cifs.CifsPublisherPlugin.xml
hudson.util.IOException2: Unable to read /home/jenkins/jenkins.plugins.publish_over_cifs.CifsPublisherPlugin.xml
at hudson.XmlFile.unmarshal(XmlFile.java:170)
at hudson.model.Descriptor.load(Descriptor.java:806)
...

active-directory.jpi
analysis-collector.jpi
analysis-core.jpi
ant.jpi
compact-columns.jpi
copyartifact.jpi
copy-to-slave.jpi
cron_column.jpi
cvs.jpi
disk-usage.jpi
email-ext.jpi
envinject.jpi
external-monitor-job.jpi
extra-columns.jpi
gerrit-trigger.jpi
git-client.jpi
git.jpi
git-parameter.jpi
greenballs.jpi
javadoc.jpi
ldap.jpi
mailer.jpi
maven-plugin.jpi
nested-view.jpi
pam-auth.jpi
parameterized-trigger.jpi
promoted-builds.jpi
publish-over-cifs.jpi
publish-over-ssh.jpi
redmine.jpi
ruby.jpi
ssh-slaves.jpi
subversion.jpi
translation.jpi
versioncolumn.jpi
versionnumber.jpi
view-job-filters.jpi
warnings.jpi
ws-cleanup.jpi

I also have this exact same problem and it causes huge issues. It is infeasible to recreate all CIFS servers, users and passwords everytime Jenkins restarts.
WARNING: Failed to load /var/lib/jenkins/jenkins.plugins.publish_over_cifs.CifsPublisherPlugin.xml
hudson.util.IOException2: Unable to read /var/lib/jenkins/jenkins.plugins.publish_over_cifs.CifsPublisherPlugin.xml

What is IOException2?

Running on Ubuntu 12.04, Jenkins 1.508

What is the status of this code? Is it up to the plug-in developers to fix their code or is a fix forthcoming for jenkins itself? As the change to xstream seems to have broken several common plug-ins this seems like a critical issue.
Thanks

You might as well revert to 1.503. I had nothing but problems with each new update after 1.503. It took a few hours to downgrade, but it was worth it. I'm surprised such a significant feature has received so little attention.

Wow, I am surprised to hear that. Kevin, did you need to downgrage the CIFS plugin as well? I may have issues with downgrading to 1.503 since the first version I stood up with this config was 1.505. Hopefully all my builds are backwards compatible...

David,

What I did:

1) Copied my current jenkins home out of the way ("old").
2) Installed fresh 1.503, and re-installed all plugins I knew of (current versions of plugins).
3) "meld"ed (a diff-merge tool for Linux) old and new configs to see things still missing in the 1.503 build. Manually installed as much as possible as far as system configuration went.
4) Manually merged global config.xml.
5) Copied over userContent/ from old.
6) Copied over the jobs from the old.
7) Iteratively kept starting and monitoring the jenkins log for exception, and tried to resolve all exception until everything was started.
8) Reset passwords because I believe the master key changes when you do this, and it breaks all your passwords. (We use ssh keys for most stuff, so, that was no big deal for us: basically slave passwords and the occasional ssh password.)

Things I ran into: views missing tree attribute, build.xml files were missing a git related element that I had to copy into all build.xml files that were missing them. I think that was about it.

If necessary, only copy over 1 job at a time until you discover most of the issues. I know the log rotation stuff also changed, which, going backward, will cause you to lose all your "keep builds..." settings. I highly recommend "Configuration Slicer" plugin for fixing those (works on 1.503, but not on newer versions.)

Hope this helps.

Can everyone with this problem please provide their os, version including architecture and the full details of the JVM that the jenkins master is using?

Ubuntu 12.04 x64

Jenkins ver. 1.508 (also happened with 1.505)
Publish Over CIFS 0.2
Credentials Plugin 1.3.1 (I don't know if this is used for CIFS or not)

java version "1.7.0_12-ea"
Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b05)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b26, mixed mode)
Which is actually openJDK
openjdk-6-jre 6b27-1.12.3-0ubuntu1~12.04.1 OpenJDK Java runtime, using Hotspot JIT

I reverted back to 1.503, so, I cannot provide precise details.

CentOS 6.4 x86_64
java-1.6.0-openjdk-1.6.0.0-1.57.1.11.9.el6_4.x86_64 (I switched to using jdk1.7.0_17 from oracle, but can't remember if I did that before or after reverting to 1.503. I believe it was AFTER.)
Publish over cifs 0.2

deleting duplicate links because this is not related to FTP or SSH. Those plugins work fine saving credentials.

I reproduce this issue when configures both Publish Over CIFS and Publish Over SSH on jenkins 1.518.
And also this issue is not reproduced when configures only Publish Over CIFS.

Still present in version 1.520

FWIW, I have abandoned this plugin. We had an issue with even 1.503 (we're still on 1.503) where I could not deploy/connect to a particular Windows box no matter what I did, when smbclient had no problems at all. So, I resorted to using:

smbclient -E -A ~/.cifs_credentials "$SHARE" -c 'prompt; recurse; mput mydir' 1>/dev/null

While not as flexible as the CIFS plugin, it works. But, smbclient does not return an error if this command line fails (so the jenkins job succeeds). I have found no good way to make smbclient fail whenever there is a problem (like invalid credentials). One way I found to check for this is to try to put a file as a simple check (without mput):

echo "xts-$BUILD_NUMBER" > xts.build
smbclient -E -A ~/.cifs_credentials "$SHARE" -c 'put xts.build' 1>/dev/null
... continue with actual smbclient copy...

This fails under a few tests I performed as I had hoped, but not all.

SHARE is //system/share type share.
~/.cifs_credentials contains:
cat ~/.cifs_credentials
username=jenkins
password=password
domain=DOMAIN

There was a fix described in another ticket, related to the FTP part of publish-over as described here https://github.com/afischer211/publish-over-ftp-plugin/blob/master/src/main/java/jenkins/plugins/publish_over_ftp/BapFtpPublisherPlugin.java . I've made the same changes in the publish-cifs plugin and it works. For anyone who's not comfortable with the source change, you can download the hpi here: http://dl.bintray.com/imavroukakis/generic/publish-over-cifs.hpi . It has also been compiled against a patched version of jifs to allow large file transfers.

We are using Jenkins 1.516 and publish-over-cifs 0.2 without any problems.
But after I installed publish-over-ssh 1.10 we also lost the CIFS shares config.

Thank you very much Ioannis, your version did the job, everything is fine again.

Can someone (bap?) do this changes in the main source tree?

Had the same problem, updated to version 0.3 today and it seems to be fixed. I'd suggest you try it.

Looks like this was fixed in 0.3

For your information, all publish-over-cifs component type JENKINS issues related to the Publish Over CIFS plugin have been transferred to Github: https://github.com/jenkinsci/publish-over-cifs-plugin/issues

Here is the direct link to this issue in Github: https://github.com/jenkinsci/publish-over-cifs-plugin/issues/41
And here is the link to a search for related issues: https://github.com/jenkinsci/publish-over-cifs-plugin/issues?q=%22JENKINS-17112%22

(Note: this is an automated bulk comment)