mkdir: cannot create directory /ssh Permission denied

Hello All,
When i tried to do post installation process on my nvidea tegra tx2 i got this message:

mkdir:cannot create directory /.ssh: permission denied
touch:cannot touch /.ssh/known?host: no such file or directory

As i understand i have the problem with ssh permission.
Do you know what should i do?
Thanks

Have you built on a PC host with a Linux filesystem ?
Windows filesystems are not suitable for this and lead to permission issues.

Of course. I use linux 14.04

The question of Linux filesystem is basically determining whether permissions were preserved. A host being Linux does not necessarily mean this is a Linux file system type (for example a live DVD won’t work…it isn’t a native Linux file system type…and some VMs try to install on NTFS…this too won’t work even though Linux runs on it).

You can use “df -H -T .” from the location of the flash.sh script and you’ll know for sure…it should be ext4.

A second place this might fail is if you used command line flash and did not use sudo with the apply_binaries.sh step.

If you used command line flash and did not unpack the sample rootfs with sudo this would also cause permission failure.

In the cases above “sudo” from the Jetson will tend to fail. Not being able to access the “.ssh” directory is very suspicious of permissions, sudo, and/or how the root file system was created being in error.

You might also try a simple “sudo ls” and see if it works.

I’ve suffered from this issue as well.

The solution I applied is “manually install”. which are already downloaded, after flashing OS.

I have a directory named “jetpack_download” within the same directory of .run file. Copy that directory to your target device, Xavier in my case.

Then install 1)cuda 2)cudnn 3)nvinfer & tensorrt 4)opencv in order.

Here’s another reference: Installing CUDA on Jetson (Manual Installation) · GitHub

Hope it helps.

That raises an interesting thought…the flash binary is for desktop PC architecture only, and won’t run on a Jetson, but I’ve never considered running the package installer directly on the Jetson.

On the other hand, JetPack downloads a copy of whatever it is going to put on the Jetson to itself first (some parts of this would refuse to run directly on the Jetson, but there are ways around that for non-flash components). Then it uses ssh. Ssh to itself will always work of course, and networking will never get in the way (although the Jetson might want to know if you are sure it is really itself…makes for an interesting conversation between the Jetson and itself). Then, after an install, there would be two copies of the local repos…one in the JetPack directory, and another in “/var”. If you were already short on space you’d have trouble getting there, but for any other case you could delete the JetPack content after you are done.