Add a mounted-to-host NFS target as disk to the container, shift = true got error

1

It looks the incus confid device add <inst> disk ... shift=true works well on local filesystem as expected, but for a nfs storage mounted on host, the shift=true must be removed - which means the container can only read from the nft dir but cannot write. Otherwise this is given -

Required idmapping abilities not available

@stgraber I’ve read another post in which you mentioned that a nfs target cannot be directly mounted in a non-privileged instance, so I mount it on the host and try to make it work in the right way (shiftfs). May I ask for your help, pls?

# root @ u24-incus-utils in /mnt/nfs [16:50:38] 
$ df -hT                                                                                                                                 
Filesystem                               Type      Size  Used Avail Use% Mounted on
tmpfs                                    tmpfs     391M  2.1M  389M   1% /run
efivarfs                                 efivarfs  256K   45K  207K  18% /sys/firmware/efi/efivars
/dev/sda1                                ext4       38G  2.9G   35G   8% /
tmpfs                                    tmpfs     2.0G     0  2.0G   0% /dev/shm
tmpfs                                    tmpfs     5.0M     0  5.0M   0% /run/lock
/dev/mapper/stor-data                    ext4      196G  7.7G  179G   5% /data
/dev/sda16                               ext4      881M  112M  708M  14% /boot
/dev/sda15                               vfat      105M  6.2M   99M   6% /boot/efi
tmpfs                                    tmpfs     100K     0  100K   0% /var/lib/incus/shmounts
tmpfs                                    tmpfs     100K     0  100K   0% /var/lib/incus/guestapi
tmpfs                                    tmpfs     391M   12K  391M   1% /run/user/0
172.21.244.6:/h03_nfs_data/data_research nfs4      6.4T  2.1G  6.1T   1% /mnt/nfs/data_research

# root @ u24-incus-utils in /mnt/nfs [16:47:15] 
$ incus list -c nsum4Nd                                                                                                                  
+---------------+---------+-----------+--------------+------------------------+-----------+-------------+
|     NAME      |  STATE  | CPU USAGE | MEMORY USAGE |          IPV4          | PROCESSES | DESCRIPTION |
+---------------+---------+-----------+--------------+------------------------+-----------+-------------+
| d11-http-file | RUNNING | 1s        | 20.94MiB     | 192.168.103.220 (eth0) | 15        |             |
+---------------+---------+-----------+--------------+------------------------+-----------+-------------+

# root @ u24-incus-utils in /mnt/nfs [16:48:49] C:1
$ incus config device add d11-http-file data_files disk source=/root path=/data/filebrowser/nfs_data_research shift=true 
Device data_files added to d11-http-file

# root @ u24-incus-utils in /mnt/nfs [16:49:05] 
$ incus config device remove d11-http-file data_files
Device data_files removed from d11-http-file

# root @ u24-incus-utils in /mnt/nfs [16:49:21] 
$ incus config device add d11-http-file data_files disk source=/mnt/nfs/data_research path=/data/filebrowser/nfs_data_research shift=true
Error: Failed to start device "data_files": Required idmapping abilities not available

# root @ u24-incus-utils in /mnt/nfs [16:50:09] C:1
$ incus config device add d11-http-file data_files disk source=/mnt/nfs/data_research path=/data/filebrowser/nfs_data_research           
Device data_files added to d11-http-file

# root @ u24-incus-utils in /mnt/nfs [16:50:21] 
$ incus config device remove d11-http-file data_files
Device data_files removed from d11-http-file
2

You have two options:

1 Like
3

Thanks for the instant and clear response, sir.
Suppose that sshfs (from one of your another posts) can be an option, which of them (sshfs, fuse-nfs) could be a better choice you’d suggested?
With that post read, I’ve done quite simple test and found out that sshfs are also working along the fuse stuff, besides it has built-in support by most distros.

4

sshfs is simpler to get going but will typically be slower than NFS as it operates through an encrypted SSH tunnel. If you’re happy with the performance of sshfs in your environment, I’d say to stick with it.

1 Like
5

sshfs is simpler to get going but will typically be slower than NFS as it operates through an encrypted SSH tunnel.

Your answer is exactly what I’m looking for. Theoretical performance diff should be known and considered, and can be tested somehow - however in my simple use case of this container, with your suggestion, I’d go with sshfs. Easy-to-use (like mounting with fstab) and reliability are kinda necessary more than perf here.