Permission denied when pushing code

[SuperBK]

This popped for us today, any ideas?

[Travis Hoffman]

Originally Posted by SuperBK

This popped for us today, any ideas?

I just got ours to work...but I don't really know what I did.

I reflashed firmware and reimaged the roboRIO multiple times using our driver station Classmate and my programming laptop. No dice.

I swapped the roboRIO with another one - no dice. Same problem.

I got a completely different laptop, updated the WPI plugins, tried to deploy, no dice.

I used the same laptop to reflash and reimage the roboRIO. I deleted the project from the workspace, then reimported it and rebuilt. At this point, it downloaded. I am not even sure that action contributed to the fix.

[Travis Hoffman]

Anyone experiencing problems, please cross-post details to the FIRST Forums thread here - http://forums.usfirst.org/showthread...-During-Deploy.

Time to make it loud.

[BradAMiller]

Originally Posted by SuperBK

This popped for us today, any ideas?

If you're familiar with Linux, could you try ssh-ing to the roboRIO as lvuser and check the permissions and ownership of files in the lvuser home directory and look for anything not owned by lvuser. It seems like somehow something is getting messed up, maybe a a download failing part way through or something.

If not, I would expect that reimaging and being sure to check the reformat box in the imaging tool would get you back. If you do that, be sure to reinstall Java if that's the language you're using.

Brad

[SuperBK]

We SSH'd to the roborio as admin, then did

chmod -R 777 /home/lvuser/

To give all users read, write, and execute permissions to the folder.

lvuser was not the owner of the /home/lvuser/ folder, to we gave all permissions to everybody.

Its now working for us.

[LG67]

Spent a gazillion hours last night trying to fix the exact same problem and your solution is a life-saver. Thank you

[AustinSchuh]

Next time someone has an issue, please log into the roboRIO run the following command and post the output here.

Log in as admin@roboRIO-<team#>-frc.local with putty or equivilent

Then, run

ls -lah /home/lvuser/

And post the results.

[SuperBK]

After updating the Eclipse plugins, we were broken again. Something, during the deploy process is TAKING AWAY the permissions for lvuser to the /home/lvuser/ folder. This happens during or before the "killall" command.

Our fix was to modify the build.xml file and add permissions back to the lvuser folder before the copy of the code over. Note that the user "admin" is used to add the permissions back, not "lvuser"

Here is a snippit of the build.xml. We added this part
<sshexec host="${target}"
username="admin"
password="${password}"
trust="true"
failonerror="false"
command="chmod 777 /home/lvuser"/>

    <sshexec host="${target}"
               username="admin"
               password="${password}"
               trust="true"
               failonerror="false"
               command="killall -q netconsole-host || :"/>
  	
  	<sshexec host="${target}"
  	               username="admin"
  	               password="${password}"
  	               trust="true"
  	               failonerror="false"
  	               command="chmod 777 /home/lvuser"/>

    <scp file="${wpilib.ant.dir}/robotCommand" todir="${username}@${target}:/home/lvuser/" password="${password}" trust="true"/>

[SuperBK]

I attached my build.xml file. (remove the .txt extension)

[carrud]

This partially worked for me. This exact placement did not resolve the Permission Denied, but moving the line to a diff spot in the .xml worked great.

BTW, for others: this .xml for me is in wpilib/cpp/current/ant

Many thanks for posting this fix.



-Clark

[rod@3711]

I am now getting the Permission Denied feature when trying to deploy. Started today after I allowed eclipse to upgrade from 4.5.1.20150917-1200 to 4.5.1.20160218-0600.

I Tried "reverting" back in Eclipse.

I tried using FileZilla to allow all permissions to home/lvuser. My changes did not seem to stick.

I tried changing changing build.xml that is ..wpilib\cpp\current\ant adding:

<sshexec host="${target}" command="chmod 777 /home/lvuser" failonerror="false" trust="true" password="${password}" username="admin"/>

at random locations.

I tried updating the firmware in the roboRio.

I did not feel comfortable that I did any of the above steps correctly, but I am still unable to deploy code.

I will try deploying with another computer this afternoon.

[SuperBK]

You may have to ssh to your roboRio first and issue the "chmod 777 /home/lvuser" to give permission to the folder, then run the modified build.xml. . After issuing the command you can do

ls -l /home/lvuser

and see if the permissions are "drwxrwxrwx" to see if your changes take.

Do you need step-by-step instructions on how to ssh to it? I use putty, a ssh client.

After doing that, try deploying again. Post the entire contents of your build log here.

Do you see se the extra chmod command in your build log?


Add exactly this (cut and paste)

<sshexec host="${target}"
username="admin"
password="${password}"
trust="true"
failonerror="false"
command="chmod 777 /home/lvuser"/>

Above the line
<scp file="${wpilib.ant.dir}/robotCommand" todir="${username}@${target}:/home/lvuser/" password="${password}" trust="true"/>

[rod@3711]

Thanx Brian,

When I had previously tried to set permissions with filezilla, I had logged on as lvuser. It probably did not the right privileges. Logged on as admin and the permission changes stuck.

Added your "chmod 777" to build.xml and voila.

You will be receiving good karma credits.

[Travis Hoffman]

Originally Posted by rod@3711

I am now getting the Permission Denied feature when trying to deploy. Started today after I allowed eclipse to upgrade from 4.5.1.20150917-1200 to 4.5.1.20160218-0600.

I THINK THIS IS KEY. The computer that works and deploys code has MARS.1 installed (4.5.1.20150917-1200). The computer that started flaking out and throwing permission denied errors has MARS.2 (4.5.1.20160218-0600), which I installed shortly prior to this problem occurring.

I will use the build.xml hack in an emergency, but I hope the developers investigate this potential blar with Eclipse developers.

[taichichuan]

Originally Posted by Travis Hoffman

I THINK THIS IS KEY. The computer that works and deploys code has MARS.1 installed (4.5.1.20150917-1200). The computer that started flaking out and throwing permission denied errors has MARS.2 (4.5.1.20160218-0600), which I installed shortly prior to this problem occurring.

I will use the build.xml hack in an emergency, but I hope the developers investigate this potential blar with Eclipse developers.

We're seeing this same issue here at 116. I wiped out the updated Mars.1 eclipse and installed Mars.2 with the exact same results -- permission denied. I still have the original Mars.1 install package. I'll try that, but I suspect that it will work until the update rolls in.

Mike A.
Mentor
FRC #116