so, after 1 year or more of messing with Unraid/Zfs and a DAS enc. I decided to move the large storage area to another server  (Dell R420) and share it out to Unraid. my question is with NFS, I am trying to figure out if I got everything correct:

 

Server:

theskaz@nas:/mnt/datastore$ sudo exportfs -v
/mnt/tank       192.168.1.39(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
/mnt/datastore  192.168.1.39(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

 Unraid:

/dev/sdb1                  /boot         vfat      rw,flush,noatime,nodiratime,dmask=77,fmask=177,shortname=mixed
/boot/bzmodules            /lib/modules  squashfs  ro,defaults
/boot/bzfirmware           /lib/firmware squashfs  ro,defaults
tmpfs                      /dev/shm      tmpfs     defaults
hugetlbfs                  /hugetlbfs    hugetlbfs defaults
192.168.1.3:/mnt/tank    /tank   nfs auto,noatime,nolock,tcp,actimeo=1800 0 0
192.168.1.3:/mnt/datastore       /datastore      nfs auto,noatime,nolock,tcp,actimeo=1800 0 0

 

 

I mirrored what the file structure was when the zfs pools were local. Does this look right?:

root@Tower:/datastore# ls -latr
total 312064341
drwxrwxrwx  5 65534 65534            5 Oct  2 10:18 influxdb/
-rwxrwxrwx  1 65534 65534 805306368000 Oct 12 11:04 sql_data.img*
drwxrwxrwx  6 65534 65534            7 Oct 15 07:12 mariadb/
drwxrwxrwx  4 65534 65534            6 Oct 26 13:10 ./
-rwxrwxrwx  1 65534 65534 322122547200 Dec  5 21:35 plotter_temp.img*
drwxr-xr-x 23 root  root           500 Dec  8 12:03 ../

 

 

the 65534 part looks odd to me.

Edited December 9, 20214 yr by TheSkaz

on reboot, fstab reverts back... what the....

Quite normal for it to revert.  OS runs entirely from RAM and any modifications to files that aren't explicitly handled via the various cfg files on the flash drive will always revert back to default.

 

Usual method for mounting shares is via the Unassigned Devices plugin.  Barring that, you have to modify the "go" file or use user scripts with an appropriate script to make changes to the in RAM files.

i added a script in user scripts to get it to mount on boot. now the issue is that I cant write to the share.

 

server 192.168.1.3:

theskaz@nas:/mnt/tank$ ls -l
total 59
drwxrwxrwx 4 nobody users 4 Oct  1 18:47 chia
drwxrwxrwx 8 nobody users 8 Oct  5 21:02 media
drwxrwxrwx 5 nobody users 6 Nov 18 21:22 netshare
drwxrwxrwx 2 nobody users 2 Nov 12 19:49 UnfiVideoShareForStorage
drwxrwxrwx 3 nobody users 4 Nov 18 23:31 vms
theskaz@nas:/mnt/tank$

 

unraid 192.168.1.39:

root@Tower:/tank# ls -l
total 17
drwxrwxrwx 2 nobody users 2 Nov 12 12:49 UnfiVideoShareForStorage/
drwxr-xr-x 2 root   root  2 Sep 30 12:55 chia/
drwxrwxrwx 8 nobody users 8 Oct  5 15:02 media/
drwxr-xr-x 2 root   root  2 Sep 30 12:55 netshare/
drwxr-xr-x 2 root   root  2 Sep 30 12:55 vms/

 

exports:

/mnt/tank       192.168.1.39(rw,sync,no_subtree_check)
/mnt/datastore  192.168.1.39(rw,sync,no_subtree_check)

 

mount command:

mount -o nolock -t nfs 192.168.1.3:/mnt/tank /tank
mount -o nolock -t nfs 192.168.1.3:/mnt/datastore /datastore

 

nobody has been mapped to 99 on nas, and users mapped to 100

50 minutes ago, Squid said:

Usual method for mounting shares is via the Unassigned Devices plugin. 

Some reason that won't work for your scenario?

1 hour ago, trurl said:

Some reason that won't work for your scenario?

giving it a try now.

Ok, that approach got me a lot closer. 

 

I had to add "no_squash_root" to the exports on the nas so that docker containers can mkdir