Permissions problems configuring a NFS server and client between Ubuntu 18.04 x64 and Ubuntu 18.04 Arm64

Hello.

Because I have a little space on the sd card of my jetson nano,I have installed the nfs server on Ubuntu 18.04 x64 bit and the nfs common client on ubuntu 18.04 for arm64 on the jetson nano. I have followed this tutorial :

I have issued the following commands :

on the server side :

sudo chown -R nobody:nogroup /home/loziomario/Scrivania/Nano/qemu-chroot-I9

chmod -R 777 /home/loziomario/Scrivania/Nano/qemu-chroot-I9

on the client / jetson nano side :

sudo chown -R nobody:nogroup /root/Scrivania/Work/qemu-chroot-I9

chmod -R 777 /root/Scrivania/Work/qemu-chroot-I9

and then I have created a script like this :

xhost +

sudo mount 192.168.1.6:/home/loziomario/Scrivania/Nano/qemu-chroot-I9  /root/Scrivania/Work/qemu-chroot-I9

sudo mount -t sysfs /sys/ /root/Scrivania/Work/qemu-chroot-I9/chroot-bionic-i386/sys/

sudo mount -t proc /proc/ /root/Scrivania/Work/qemu-chroot-I9/chroot-bionic-i386/proc/

sudo mount --bind /dev /root/Scrivania/Work/qemu-chroot-I9/chroot-bionic-i386/dev/

sudo mount --bind /dev/pts /root/Scrivania/Work/qemu-chroot-I9/chroot-bionic-i386/dev/pts/

sudo mount --bind /dev/shm /root/Scrivania/Work/qemu-chroot-I9/chroot-bionic-i386/dev/shm/

I’ve logged inside the chroot with this command :

sudo chroot /root/Scrivania/Work/qemu-chroot-I9/chroot-bionic-i386/ /bin/su -l root

Ok.

I tried to update and upgrade the packages of the i386 chroot and this is what happened :

apt update

.......

Run apt list --upgradable to see it.

W: chown to _apt:root of directory /var/lib/apt/lists/partial failed

- SetupAPTPartialDirectory (1: Operation not permitted)

W: chown to _apt:root of directory /var/lib/apt/lists/auxfiles failed -

SetupAPTPartialDirectory (1: Operation not permitted)

W: Not using locking for nfs mounted lock file /var/lib/apt/lists/lock

W: Download is performed unsandboxed as root as file /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_bionic_InRelease' couldn't be accessed by user '_apt'. -

pkgAcquire::Run (13: Permission denied)W: chown to root:root of file /var/lib/apt/lists/partial/it.archive.ubuntu.com_ubuntu_dists_bionic_InRelease failed - Operation not permitted)


root@ziomario-desktop:~# apt upgrade


Reading package lists... DoneBuilding dependency tree      

Reading state information... Done

Calculating upgrade... Done

The following packages will be upgraded:  teamviewer1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Need to get 15.6 MB of archives. After this operation, 0 B of additional disk space will be used.

W: Not using locking for nfs mounted lock file /var/lib/dpkg/lock-frontendW: Not using locking for nfs mounted lock file /var/lib/dpkg/lockW:

chown to _apt:root of directory /var/cache/apt/archives/partial failed

- SetupAPTPartialDirectory (1: Operation not permitted)

W: chown to _apt:root of directory /var/lib/apt/lists/auxfiles failed

- SetupAPTPartialDirectory (1: Operation not permitted)

W: Not using locking for nfs mounted lock file /var/cache/apt/archives/lock

Do you want to continue? [Y/n]

something is wrong with the permissions ?. I’m not able to understand what’s wrong.

This is how I have configured the NFS on the server side :

sudo nano /etc/exports

/home/loziomario/Scrivania/Nano/qemu-chroot-I9  192.168.1.3(rw,sync,no_subtree_check)

where :

192.168.1.3 : is the ip of the nano

/home/loziomario/Scrivania/Nano/qemu-chroot-I9 : the folder that I want to make available only to the ip number of the nano

on the client / nano side I did :

sudo mount 192.168.1.6:/home/loziomario/Scrivania/Nano/qemu-chroot-I9  /root/Scrivania/Work/qemu-chroot-I9

where :

192.168.1.6 : is the IP of the server,ubuntu 18.04 64 bit

/home/loziomario/Scrivania/Nano/qemu-chroot-I9 : is the folder of the server that I want to make available to client-nano

/root/Scrivania/work/qemu-chroot-I9 : is the folder where I want to mount the folder of the server

this is the mixed full (network) path where It is saved the chroot i386,that I want to access through the nano :

/root/Scrivania/Work/qemu-chroot-I9/chroot-bionic-i386/

on the server side :

root@loziomario-I9:/home/loziomario/Scrivania/Nano/qemu-chroot-I9# sudo chown -R nobody:nogroup chroot-bionic-x86_64
root@loziomario-I9:/home/loziomario/Scrivania/Nano/qemu-chroot-I9# chmod 777 -R chroot-bionic-x86_64

on the client side :

sudo chown -R nobody:nogroup chroot-bionic-x86_64

chown: changing ownership of 'chroot-bionic-x86_64/sys/kernel/config': Operation not permitted
chown: changing ownership of 'chroot-bionic-x86_64/sys/kernel/tracing': Operation not permitted
chown: changing ownership of 'chroot-bionic-x86_64/sys/kernel/debug': Operation not permitted
chown: changing ownership of 'chroot-bionic-x86_64/sys/fs/pstore': Operation not permitted
chown: changing ownership of 'chroot-bionic-x86_64/sys/fs/cgroup': Operation not permitted
chown: changing ownership of 'chroot-bionic-x86_64/sys/fs/fuse/connections': Operation not permitted

and so on…

chmod 777 -R chroot-bionic-x86_64

chmod: changing permissions of 'chroot-bionic-x86_64/sys/kernel/config': Operation not permitted
chmod: changing permissions of 'chroot-bionic-x86_64/sys/kernel/tracing': Operation not permitted
chmod: changing permissions of 'chroot-bionic-x86_64/sys/kernel/debug': Operation not permitted

and so on…

sudo chroot ./chroot-bionic-x86_64/ /debootstrap/debootstrap --second-stage

/bin/mknod: //test-dev-null: Operation not permitted
E: Cannot install into target '/' mounted with noexec or nodev

I have also tried to do :

on the server side :

sudo mount -o remount,exec,dev /

ok

on the client side :

sudo mount -o remount,exec,dev /

sudo chroot ./chroot-bionic-x86_64/ /debootstrap/debootstrap --second-stage
/bin/mknod: //test-dev-null: Operation not permitted
E: Cannot install into target '/' mounted with noexec or nodev

I hope that everything is clear and that someone can give me some good suggestion to fix the permission problems that I have. thanks.

when using NFS boot with server on aarch64 jetson
but with another jetson booting from it over the network
it wouldn’t run unless the rootfilesystem is copied from Jetpack folder with arguments preserving permissions/ sticky bit

rsync -avzhprt  192.168.x.x:/path/rootfs_nx /path/

using this to transfer the rootfilesystem folder generated by sdkmanager it was fine to get another jetson to boot from it over the network
using steps to setup NFS server as follows
https://developer.ridgerun.com/wiki/index.php/Setting_Up_A_NFS_Service
hope that helps

this is what I did on the server side :

rsync -avzhprt 192.168.1.3:/root/Scrivania/Work/qemu-chroot-I9 /home/loziomario/Scrivania/Nano/qemu-chroot-I9

and here you find the full log with the errors that I’ve got :

https://drive.google.com/file/d/160ltaKsMe16R47qCOPNJl4SDEY9NhXPk/view

rsync also might need to be done from root user/to root user
I did not try with quemu
I just took the default rootfs folder generated by sdkmanager at host PC

on the server side I’m root even if I’m using the user account “loziomario” :

root@loziomario-I9:/etc/ssh# rsync -avzhprt 192.168.1.3:/root/Scrivania/Work/qemu-chroot-I9 /home/loziomario/Scrivania/Nano/qemu-chroot-I9

what do u mean with “I just took the default rootfs folder generated by sdkmanager at host PC” : I never did something like that. please explain.

there is rootfs available for download from the Download center
also it is generated by sdkmanager by the time of flashing jetson device so it remains located in Host PC Jetpack folder as “rootfs” folder; it could be used to be booted from
you may find rootfs folder at Host PC in the jetpack folder in Linux for Tegra subfolder somewhere

I think that I found the way to make work the rsync. I gave the same command as before,but not from the server,but from the client (on the nano) and it is doing its job without errors,this time. I don’t know if this will fix the chroot / apt problems anyway,lets see,

1 Like

it seems that you are not using NFS boot but just using nfs server for file exchange?
the idea is still the same - to export the NFS export path. also rsync files preserving attributes
it might work

To make work the ubuntu 18.04 / I386 chroot I don’t need to boot it. I just only need to fix the permissions. it’s going slow. too much. At this point I’m realizing that maybe it does not worth it. The problem that I have is that I can’t attach an USB disk,because my nano (powered by the AC power cable) is not able to be turned on. It is able to be powered stably only in headless mode. It goes in read only mode even if I touch the board a little. So,the NFS is the only choice that I have ? because I can’t store on the sd card almost anything. 64 gb end soon.

there are large sdcards around up to 1tb
maybe more power will do the trick for usb peripherals? e.g. Adafruit 5V 4A switching power supply GEO241DA-0540 5V 4A (4000mA) switching power supply - UL Listed : ID 1466 : $14.95 : Adafruit Industries, Unique & fun DIY electronics and kits

maybe it’s enough only to fix the permissions for some special files ? for example for all the content inside the /var folder ? it will help to save time…

I’ve got this : GeeekPi DC 5V 4A Alimentatore con EU&UK&US Spina per Raspberry Pi X820/X825 SATA Expansion Board/ X700 ups/ X720/ X735 Power Management Board/Jetson Nano/X822/X852/T300/T100/T200/X750 ; is not similar to the one suggested by you ? even with this,the board goes in read only at a minimum touch. And to turn it again,I should extract the sd card and I should re insert it. Otherwise,it stucks on the nvidia logo. I know…I’ve seen the sd card of 1 TB. But they are expensive…

I did not read all of this, but do beware that using names for chown/chgrp will only work if both systems have the same numeric IDs for those names/groups. Compare on the host PC and the Jetson the output of below:

grep 'nobody' /etc/passwd
grep 'nogroup' /etc/group

…if numeric IDs differ, then any rsync command would need to run as root/sudo and include this option:
--numeric-ids

it does not work. this is what I did :

sudo mount 192.168.1.6:/home/loziomario/Scrivania/Nano/qemu-chroot-I9 /root/Scrivania/Work/qemu-chroot-I9
rsync -avzhprt 192.168.1.3:/root/Scrivania/Work/qemu-chroot-nano/chroot-groovy-x86_64 /root/Scrivania/Work/qemu-chroot-I9

where :

192.168.1.3 : ip of the jetson nano
192.168.1.6 : ip of the server

/home/loziomario/Scrivania/Nano/qemu-chroot-I9 = folder on the server where the chroot groovy should be saved (path destination on the server)

/root/Scrivania/Work/qemu-chroot-I9 = folder on the nano where the chroot groovy should be saved (path destination on the client)

/root/Scrivania/Work/qemu-chroot-nano/chroot-groovy-x86_64 = path on the nano where is saved the chroot groovy (path source on the client)

qemu-chroot-I9 = the shared folder between nano and server,where the chroot groovy should be copied

all the files have been copied correctly. After this,I did :

xhost +
sudo mount -t sysfs /sys/ /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/sys/
sudo mount -t proc /proc/ /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/proc/
sudo mount --bind /dev /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/
sudo mount --bind /dev/pts /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/pts/
sudo mount --bind /dev/shm /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/shm/
sudo chroot /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/ /bin/su -l root

and this is what happened :

root@ziomario-desktop:~# apt update

Hit:1 http://archive.ubuntu.com/ubuntu groovy InRelease
Get:2 http://archive.ubuntu.com/ubuntu groovy/main Translation-en [507 kB]
Fetched 507 kB in 16s (31.3 kB/s)
Reading package lists… Done
Building dependency tree… Done
All packages are up to date.
W: Not using locking for nfs mounted lock file /var/lib/apt/lists/lock

root@ziomario-desktop:~# apt install nano

Reading package lists… Done
Building dependency tree… Done
Suggested packages:
hunspell
The following NEW packages will be installed:
nano
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 284 kB of archives.
After this operation, 930 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/main amd64 nano amd64 5.2-1 [284 kB]
Fetched 284 kB in 1s (191 kB/s)
debconf: DbDriver “config”: /var/cache/debconf/config.dat is locked by another process: No locks available
dpkg: error: unable to lock dpkg database lock: No locks available
W: Not using locking for nfs mounted lock file /var/lib/dpkg/lock-frontend
W: Not using locking for nfs mounted lock file /var/lib/dpkg/lock
W: Not using locking for nfs mounted lock file /var/cache/apt/archives/lock

E: Sub-process /usr/bin/dpkg returned an error code (2)

grep 'nobody' /etc/passwd on the server = nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
grep 'nobody' /etc/passwd on the client = nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

grep 'group' /etc/passwd on the server = nogroup:x:65534:
grep 'group' /etc/passwd on the client = nogroup:x:65534:

on the server side,inside the file /etc/exports there is :

/home/ *(rw,insecure,no_root_squash,no_subtree_check)

Actually I did another experiment. I have tried to install the groovy chroot directy on the shared folder like this :

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9/# debootstrap --foreign --arch amd64 groovy chroot-groovy-x86_64

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9# sudo mount -t sysfs /sys/ /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/sys/

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9# sudo mount -t proc /proc/ /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/proc/

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9# sudo mount --bind /dev /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9# sudo mount --bind /dev/pts /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/pts/

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9# sudo mount --bind /dev/shm /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/shm/

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9# cp /usr/bin/qemu-x86_64-static /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/usr/bin

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9# sudo chroot ./chroot-groovy-x86_64/ /debootstrap/debootstrap --second-stage

output :

gpgv: Signature made Thu Oct 22 16:33:11 2020 CEST
gpgv: using RSA key 871920D1991BC93C
gpgv: Good signature from “Ubuntu Archive Automatic Signing Key (2018) ftpmaster@ubuntu.com”
dpkg: error: unable to lock dpkg frontend lock: No locks available
dpkg: error: unable to lock dpkg frontend lock: No locks available
dpkg: error: unable to lock dpkg frontend lock: No locks available

can someone help me ?

I first wanted to mention your rsync command must be run sudo (didn’t see sudo with your rsync, but maybe you had this anyway), and you can only guarantee a valid copy across systems via rsync if you have “--numeric-ids”, or if the users and groups have exact matching account names and passes on both systems (this looks to be an exact match, at least for user/group nobody/nogroup…do all IDs match on all account names on both systems?).

Without sudo all numeric IDs will be translated and not preserved in a case where an rsync attempts to preserve IDs of another user…it is only root who can manipulate and preserve IDs of different users without translating. So even if accounts match numerically and in name, lack of sudo will also cause a failure in most rsync commands involving a user name/group different than the user running rsync.

I don’t know about the rest of the issues (NFS may do its own ID translation), but you’ll need to verify your rsync was run sudo, and preferably has “--numeric-ids” (using “--numeric-ids” is much easier than verifying all computers involved have exactly matching user and group name-to-ID content).

sudo rsync -avzhprt --numeric-ids /root/Scrivania/Work/qemu-chroot-nano/chroot-groovy-x86_64 /root/Scrivania/Work/qemu-chroot-I9

xhost +
sudo mount -t sysfs /sys/ /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/sys/
sudo mount -t proc /proc/ /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/proc/
sudo mount --bind /dev /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/
sudo mount --bind /dev/pts /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/pts/
sudo mount --bind /dev/shm /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/dev/shm/
sudo chroot /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/ /bin/su -l root

where :

/root/Scrivania/Work/qemu-chroot-nano/chroot-groovy-x86_64 = the place on the nano where I have saved the chroot groovy : it works great if I run it from this place.

/root/Scrivania/Work/qemu-chroot-I9 = the path of the shared folder (nano-arch64 / ubuntu x64)

root@ziomario-desktop:~# apt install nano
Reading package lists… Done
Building dependency tree… Done
Suggested packages:
hunspell
The following NEW packages will be installed:
nano
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 284 kB of archives.
After this operation, 930 kB of additional disk space will be used.
Get:1 Index of /ubuntu groovy/main amd64 nano amd64 5.2-1 [284 kB]
Fetched 284 kB in 1s (324 kB/s)
debconf: DbDriver “config”: /var/cache/debconf/config.dat is locked by another process: No locks available
dpkg: error: unable to lock dpkg database lock: No locks available
W: Not using locking for nfs mounted lock file /var/lib/dpkg/lock-frontend
W: Not using locking for nfs mounted lock file /var/lib/dpkg/lock
W: Not using locking for nfs mounted lock file /var/cache/apt/archives/lock
E: Sub-process /usr/bin/dpkg returned an error code (2)

according with this post : apt - "debconf: DbDriver "config": config.dat is locked by another process: Resource temporarily unavailable" while installing packages - Ask Ubuntu

it says :

sudo fuser -v /var/cache/debconf/config.dat

Will show you what process is holding the lock:

good. I gave this command from within the chroot like this :

root@ziomario-desktop:~/Scrivania/Work/qemu-chroot-I9# sudo chroot /root/Scrivania/Work/qemu-chroot-I9/chroot-groovy-x86_64/ /bin/su -l root

root@ziomario-desktop:~# sudo fuser -v /var/cache/debconf/config.dat

output = nothing

I gave this command also on the server side :

root@loziomario-I9:/home/loziomario/Scrivania/Nano# sudo fuser -v /var/cache/debconf/config.dat

output = nothing

so,nothing is holding the lock ?


this is even more interesting :

root@ziomario-desktop:/var/cache/debconf# mv config.dat config.dat_

root@ziomario-desktop:/var/cache/debconf# ls

config.dat-old config.dat_ passwords.dat templates.dat templates.dat-old

root@ziomario-desktop:/var/cache/debconf# apt install nano
Reading package lists… Done
Building dependency tree
Reading state information… Done
Suggested packages:
hunspell
The following NEW packages will be installed:
nano
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/284 kB of archives.
After this operation, 930 kB of additional disk space will be used.
debconf: DbDriver “config”: /var/cache/debconf/config.dat is locked by another process: No locks available
dpkg: error: unable to lock dpkg database lock: No locks available
W: Not using locking for nfs mounted lock file /var/lib/dpkg/lock-frontend
W: Not using locking for nfs mounted lock file /var/lib/dpkg/lock
W: Not using locking for nfs mounted lock file /var/cache/apt/archives/lock
E: Sub-process /usr/bin/dpkg returned an error code (2)

you are checking the lock from chroot? what if you do it from outside of the chroot? e.g using absolute path for the chroot-environment file?

they are two differfnt environments
the desktop
versus the chrooted environment
so there will be at least two different absolute paths: one path for each of the two