Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-8424

Permission denied to upload artifacts to Nexus

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • maven-plugin
    • None
    • ubuntu-10.10

      After installing the new hudson.war made available by olamy which fixed JENKINS-8387, I still got the same problem during deploy phase.

      Everything works for a "clean install", but for a "clean deploy" things get a little messy: build two times in a row made the first build ok, but the second failed during deploy phase (access denied to Nexus).

      The difference between the builds is that on the first one, maven had to download some dependencies. The second time everything was already in the local repository. If I manually remove some of my project dependencies, the build will work one more time, and then break if I build again.

      More info: http://hudson.361315.n4.nabble.com/Maven3-builds-won-t-authenticate-with-nexus-td3175639.html

          [JENKINS-8424] Permission denied to upload artifacts to Nexus

          Olivier Lamy added a comment -

          uhm I don't see something related to hudson here.
          Because those happen during the maven build and here hudson only listen and collect datas.
          If hudson (maven-plugin) was the cause you will probably have for all builds.
          I suspect more issues with your local metadata : have you try running your build with -U ?

          Olivier Lamy added a comment - uhm I don't see something related to hudson here. Because those happen during the maven build and here hudson only listen and collect datas. If hudson (maven-plugin) was the cause you will probably have for all builds. I suspect more issues with your local metadata : have you try running your build with -U ?

          tonylampada2 added a comment -

          You got the info that the build works if I do it using a shell-type build, but it breaks on a maven-type build, right?
          And it does happen for all builds.

          You´re right about the -U. If I add it, it will work everytime, but it breaks as soon as I take it off (see attached build logs).

          I still think it is related to Hudson.
          It only happens using maven inside hudson on a maven2/3-type project

          If you need I´ll be glad to run more tests here.

          tonylampada2 added a comment - You got the info that the build works if I do it using a shell-type build, but it breaks on a maven-type build, right? And it does happen for all builds. You´re right about the -U. If I add it, it will work everytime, but it breaks as soon as I take it off (see attached build logs). I still think it is related to Hudson. It only happens using maven inside hudson on a maven2/3-type project If you need I´ll be glad to run more tests here.

          Scott Oster added a comment -

          I can confirm I have this problem as well. If I use a different username/password for the artifact downloading (my nexus group) than I use for the distribution server (my nexus release repo), it does not work. If I change them all to be the same username/password and give my "release user" all permissions it works fine.

          How I normally have it setup is a "jenkins" nexus user that has read only rights to my nexus group; all my jenkins builds use this account (via settings.xml). Then I added a "release" nexus user that has write access to the release repository in nexus. My release build just added this server/username/password to my settings.xml; keeping the other server setting for the nexus group. This failed as above. When I changed the nexus group server/username/password to be the same user as the release repository, it worked.

          THIS WORKS:
          <servers>
          <!-- This server.id matches my nexus group -->
          <server>
          <id>nexus-group</id>
          <username>release</username>
          <password>****</password>
          </server>
          <!-- This server.id matches my release repository -->
          <server>
          <id>nexus-releases</id>
          <username>release</username>
          <password>****</password>
          </server>
          </servers>

          THIS DOESN'T:
          <servers>
          <!-- This server.id matches my nexus group -->
          <server>
          <id>nexus-group</id>
          <username>jenkins</username>
          <password>****</password>
          </server>
          <!-- This server.id matches my release repository -->
          <server>
          <id>nexus-releases</id>
          <username>release</username>
          <password>****</password>
          </server>
          </servers>

          Scott Oster added a comment - I can confirm I have this problem as well. If I use a different username/password for the artifact downloading (my nexus group) than I use for the distribution server (my nexus release repo), it does not work. If I change them all to be the same username/password and give my "release user" all permissions it works fine. How I normally have it setup is a "jenkins" nexus user that has read only rights to my nexus group; all my jenkins builds use this account (via settings.xml). Then I added a "release" nexus user that has write access to the release repository in nexus. My release build just added this server/username/password to my settings.xml; keeping the other server setting for the nexus group. This failed as above. When I changed the nexus group server/username/password to be the same user as the release repository, it worked. THIS WORKS: <servers> <!-- This server.id matches my nexus group --> <server> <id>nexus-group</id> <username>release</username> <password>****</password> </server> <!-- This server.id matches my release repository --> <server> <id>nexus-releases</id> <username>release</username> <password>****</password> </server> </servers> THIS DOESN'T: <servers> <!-- This server.id matches my nexus group --> <server> <id>nexus-group</id> <username>jenkins</username> <password>****</password> </server> <!-- This server.id matches my release repository --> <server> <id>nexus-releases</id> <username>release</username> <password>****</password> </server> </servers>

          pau sabats added a comment -

          Same problem of access denied both using maven or curl in order to upload an artifact to Nexus from or bat() sentence using Jenkinsfile.

          Using the curl command in a terminal works:

          "> curl -v  -u user:passwd --upload-file c:\path\file.zip http://localnexus:80801/file.zip"

          Nevertheless, the same command in a jenkinsfile returns access denied without any more information.

          So...the problem is not just for maven uploads, because I was uploading a zip of a netcore raw artifact using 'curl'.

          Weird part is that it worked some days ago.

          Now all my jenkinsfiles uploading to nexus doesn't work so I augmented the priority of the issue to critical, because it can be even blocker.

           

           

          pau sabats added a comment - Same problem of access denied both using maven or curl in order to upload an artifact to Nexus from or bat() sentence using Jenkinsfile. Using the curl command in a terminal works: "> curl -v  -u user:passwd --upload-file c:\path\file.zip http://localnexus:80801/file.zip " Nevertheless, the same command in a jenkinsfile returns access denied without any more information. So...the problem is not just for maven uploads, because I was uploading a zip of a netcore raw artifact using 'curl'. Weird part is that it worked some days ago. Now all my jenkinsfiles uploading to nexus doesn't work so I augmented the priority of the issue to critical, because it can be even blocker.    

          pau sabats added a comment -

          Workaround solution:

          (Reproduced the problem using the latest docker version of Jenkins using docker for windows.)

          The problem is related with a misconfiguration of jenkins' connection with Nexus when various user sessions are connected to the machine.

          I've tested that when two different users are using jenkins, each within their own session, the problem will occur and it will be reproduced in both users. So when the machine is restarted, this "internal bug configuration is cleaned", and the user can deploy to Nexus. But if another user logs-in, the problem may happen.

          Waiting if someone who has this issue can test if restarting the machine (not just jenkins or nexus) solves the problem, and if various user sessions have used the machine.

           

           

           

           

          pau sabats added a comment - Workaround solution: (Reproduced the problem using the latest docker version of Jenkins using docker for windows.) The problem is related with a misconfiguration of jenkins' connection with Nexus when various user sessions are connected to the machine . I've tested that when two different users are using jenkins, each within their own session, the problem will occur and it will be reproduced in both users. So when the machine is restarted , this "internal bug configuration is cleaned", and the user can deploy to Nexus. But if another user logs-in, the problem may happen. Waiting if someone who has this issue can test if restarting the machine (not just jenkins or nexus) solves the problem, and if various user sessions have used the machine.        

            Unassigned Unassigned
            tonylampada2 tonylampada2
            Votes:
            4 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: