Unable to mount second share

Joined
Dec 29, 2021
Messages
6
Good morning all,

I am having issues creating a second unix share on my truenas box. I was able to get the first share set up and mounted on a server running Ubuntu 20, and even figured out how to allow writes to TrueNas while being root or sudoing on the client. I went to create a new share for a second server and hit a brick wall. No matter what I try, I am not being allowed to mount the share. Ubuntu is telling me the operation is not permitted, Centos is saying that the resource doesn't exist (or something to that effect). I've outlined as much as I can think of below. If there is anything left out please let me know. I've been on TrueNas for less than a week, so I'm not 100% sure where to find logs and such. I will be more than happy to provide any information needed.

Here is the process I used to create the share:

Add Dataset for mailsvr use.
  • Full Name: Mail Server
  • Comment: Mailserver backup location.
  • Sync: Inherit (standard)
  • Compression Level: Inherit (lz4)
  • Enable Atime: Inherit (on)
  • Encryption Options: Inherit (Non-Encrypted)
  • ::::Opther Options::::
  • ZFS Deduplication: Inherit (off)
  • Case Sensitivity: Mixed
  • Share Type: Generic:

Add user 'mailsvr'
  • Full Name: Mail Server
  • Username: mailsvr
  • No email
  • Set password 'hT7gU5#aDhxSmtEN'
  • "New Primary Group" is checked
  • No Aux groups
  • Directory: /mnt/storage/mailsvr-backup
  • Shell: sh (I will eventually change to nologin)
  • Samba Auth is checked
  • Home Directory Perms: 744

Create Unix Share
  • Path: /mnt/storage/mailsvr-backup/ (it created a mailserver subdir here, but I did not choose it for the share root to match the setting in the user creation process.)
  • Description: Share for Mailsvr backups
  • ALl dirs: Unchecked
  • Quiet: Unchecked
  • Enabled: Checked
  • ::::Advanced Options::::
  • Read Only: Unchecked
  • Maproot User: mailsvr
  • Maproot Group: mailsvr
  • All nets hosts and nets are authorized.

One note, I have the maproots set because I need to run my backups as root to make sure it gets all of the files. This setting allowed me to access the share as root using sudo on the first share that I got working.

On the mailserver, attepmting to mount the share doesn't work. I am able to view both shares on the TrueNas box (mulungu is working) from the mail server, but I cannot connect to the new share from the mail server.
Both shares are unix shares and I'm pretty sure I used identical processess to create the both.
Code:
Last login: Sat Jan  1 09:45:59 2022 from 192.168.1.2


[root@mail tymier]# df -h
Filesystem                             Size  Used Avail Use% Mounted on
/dev/mapper/newdrive-vm--101--disk--0   49G  2.5G   45G   6% /
none                                   492K  4.0K  488K   1% /dev
udev                                    12G     0   12G   0% /dev/tty
tmpfs                                   12G     0   12G   0% /dev/shm
tmpfs                                   12G   17M   12G   1% /run
tmpfs                                   12G     0   12G   0% /sys/fs/cgroup
tmpfs                                  410M     0  410M   0% /run/user/0
tmpfs                                  410M     0  410M   0% /run/user/1000
[root@mail tymier]# show mount -e nas.tyd-it.local
bash: show: command not found
[root@mail tymier]# showmount -e nas.tyd-it.local
Export list for nas.tyd-it.local:
/mnt/storage/mailsvr-backup               (everyone)
/mnt/storage/mulungu.tyd-it.local/mulungu 10.0.0.4,10.0.0.2,192.168.1.2
[root@mail tymier]# ll /nas
ls: cannot access /nas: No such file or directory
[root@mail tymier]# ll /nfs
total 4
drwxr-xr-x 2 root root 4096 Dec 31 20:40 backups
[root@mail tymier]# ll /backups
ls: cannot access /backups: No such file or directory
[root@mail tymier]# ll /nfs/backups
total 0
[root@mail tymier]# mount nas.tyd-it.local:/mnt/storage/mailsvr-backup /nfs/backups/
mount.nfs: Operation not permitted
[root@mail tymier]# mount -t nfs nas.tyd-it.local:/mnt/storage/mailsvr-backup /nfs/backups/
mount.nfs: Operation not permitted
[root@mail tymier]# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"


CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"


I also tried mounting the share using linux subsystem for windows running Ubuntu 20 which did not work. This is strange because the mulungu server that is connected to its share also runs Ubuntu 20. When given the mount command, I am told there is no such device:

Code:
root@muthaship:/home/tymier# showmount -e nas.tyd-it.local
Export list for nas.tyd-it.local:
/mnt/storage/mailsvr-backup               (everyone)
/mnt/storage/mulungu.tyd-it.local/mulungu 10.0.0.4,10.0.0.2,192.168.1.2
root@muthaship:/home/tymier# ll /nfs
total 0
drwxr-xr-x 1 root root 4096 Dec 31 21:00 ./
drwxr-xr-x 1 root root 4096 Dec 31 21:00 ../
drwxr-xr-x 1 root root 4096 Dec 31 21:00 backups/
root@muthaship:/home/tymier# mount nas.tyd-it.local:/mnt/storage/mailsvr-backup/ /nfs/backups/
mount.nfs: No such device
root@muthaship:/home/tymier# mount -t nfs nas.tyd-it.local:/mnt/storage/mailsvr-backup/ /nfs/backups/
mount.nfs: No such device
root@muthaship:/home/tymier#


I cannot get this figured out. Is this a limitation of the Core version? One share and that's it? I highly doubt it but I'm out of ideas.
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
Are those trailing slashes correct? I don't think you are supposed to use them.

You might also want to try using mount_nfs instead
 
Joined
Dec 29, 2021
Messages
6
I tried mounting without any trailing slashes and got the same issue. I ran with -v to see if that would give me any more information

Code:
[root@mail tymier]# mount -t nfs nas.tyd-it.local:/mnt/storage/mailsvr-backup /nfs/backups -v
mount.nfs: timeout set for Mon Jan  3 11:02:39 2022
mount.nfs: trying text-based options 'vers=4.1,addr=10.0.0.7,clientaddr=10.0.0.4'
mount.nfs: mount(2): Operation not permitted
mount.nfs: trying text-based options 'addr=10.0.0.7'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.0.7 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.0.0.7 prog 100005 vers 3 prot UDP port 811
mount.nfs: mount(2): Operation not permitted
mount.nfs: Operation not permitted


And I cannot find any repo providing mount_nfs. I was able to find it for FreeBSD via google, but nothing for Centos.
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
Joined
Dec 29, 2021
Messages
6
I've done a bit more digging and making myself familiar with how FreeBSD works. Here is what I've done:

I've reinstalled TrueNAS 4 or 5 times to try different configurations.
I've been able to get the Windows SMB shares to work on my windows computer.
I cannot get any of my Linux servers to connect to the share.
Right now I'm testing using WSL and Ubuntu 20
I've verified that TrueNAS is using NFS4
I am able to see the share with showmount -e. I've tried specifying IPs and not specifying IPs both give the same result. Below represents my current configuration which requires the client to be in the network 10.0.0.0/24 or 192.168.1.0/24

1642265717444.png


The machine above is in the 192.168.1.0/24 network.

I've noticed that when restarting the server, or just the nfs server gives the following in the log:
Here I made sure nfs was actually installed as a service
Restarted it
Then grepped the log for nfsd messages and found the can't register svc name messages.

I've never seen this before. It will show up whenever I reboot the entire server, or just the nfs daemon.

SMB seems to be working fine, but I'd prefer not to use it on my Linux servers (for no reason other than I want to make NFS work).

Is there anyone out there that know's what I'm missing. I'd be happy to run any command, provide any log that will help.

1642265807334.png
 

Attachments

  • 1642265525882.png
    1642265525882.png
    6.2 KB · Views: 127
Top