FreeNAS-11.2-U7: NFS share with Ubuntu 18.04.3 LTS

[René Labounek]

Dear FreeNAS community,

I have built and setup freeNAS server (hostname ganglium). The pool is set as follows, the pool owner is the nobody and group is also nobody.

I plan to share it via SMB and via nfs. SMB sharing is succesfull and appears to work without troubles. The used SMB settings is listed below.

For the nfs setting, I have read or watched several instructions/tutorials, e.g. [1,2,3]. I have selected to use the freenas documentation instructions [1] and have set the NFS as follows:

The mount has passed succesfuly, but I am not able to read what is inside the ganglium-raid1 folder from my Ubuntu machine (hostname dendrit):

Code:

labounek@dendrit:~$ sudo mount -t nfs ganglium:/mnt/ganglium-raid1 /mnt/ganglium-raid1
labounek@dendrit:~$ cd /mnt/ganglium-raid1/
labounek@dendrit:/mnt/ganglium-raid1$ ls -l
ls: directory is being reading '.': Operation denied
total 0
labounek@dendrit:/mnt/ganglium-raid1$

The user labounek has the same username and UID 1000 over both machines and is the member of groups nobody (GID 65534) and nogroup (65533) at the FreeNAS server. At the Ubuntu machine the group called nogroup with GID 65534 exists after system instalation, so I have set user labounek to be the member of this group at the Ubuntu machine. While the comunication should be GID sensitive and not group name sensitive, I believe different group names over machines for the GID 65534 should not matter. Am I right? If not FreeNAS and Ubuntu default GIDs are inconsistent.

I have also tried to set only the MapAll User at the root as suggested in [2,3] (MapAll GRoup was set as empty), and have set owner of the ganglium-raid1 folder at root user and wheel group. It helped that I was able to read inside the folder and write into the folder and its sub-folders. But the owner of new files or new folders was root at the FreeNAS server. I do not find it very useful and secure solution.

Please any ideas what could be wrong? I am not able to see it. I have also attached the debug file.

Kind regards,
Rene

 

[KrisBee]

From your screen caps you appear to be (a) sharing the whole pool rather than individual datasets within it and (b) simultaneously sharing the same data via to different protocols, namely SMB and NFS. You need to re-think what you're doing.

1. Store your data in datasets
2. If you need to access the same data from both windows and linux clients stick to SMB only.
3. No need to add users to the nobody group
4. Your Pool mountpoint - /mnt/ganglium-raid1 - is best left as root/wheel for owner/group

 

[René Labounek]

Dear KrisBee,
many thanks for the feedback. I have several more questions about it or comments. Please can

ad 1. Why is it a problem to share the whole pool? I still consider it as one big extternal hardrive which I can see whole from other computers. Why is it a problem?

ad 2. Yes I need see the same data from different OSs. Until now, I believed samba will not allow to me acces to the data through terminal at the linux machine. It is laso crucial property for me. Folowing source is suggesting me that I could be wrong at that it can be possible to acces to the SMB drive via terminal [4]. If it is right, I can move at my linux machine from nfs access to the SMB access. I will look today how it is with the /etc/fstab settings, etc. for the SMB access. Still, is not nfs access faster and more optimized for linux machines? I will test it today and let you know.

ad 3. If nobody user and group are owners of the shared dataset (or acces point, i.e. /mnt/ganglium-raid1), how users "labounek" or "user2" will be allowed to access inside the dataset when the permissons are set to: "rwxrwx---" (first screen right window there)? Should I change the permissions for the access point at: "rwxr-xr-x"? Then I can imagine that everyone would be allowed to read what is inside the access point. I only do not really like to allow to the world to do anything at my HDDs.

ad 4. So why the FreeNas documentation is writing following step in the NFS configuration tutorial?
"In the Change Permissions screen of the pool or dataset that is being shared, change the owner and group to nobody and set the permissions according to the desired requirements."

 

[KrisBee]

Point 1. The top level of your pool needs to say as root/wheel for owner/group, so you should at least create one dataset below /mnt/ganglium-raid1 on your pool. But treating/thinking of your data as one big drive means you may not be using the full potential of zfs. Have you never used multiple partitions on a linux machine or windows were the data is partitioned and appears on separate drive letters as you want to divide your data by usage, owner or frequency of update for example? As each dataset created on a pool is a separate filesystem you can think of this as partitioning your data. You can vary the zfs properties of each dataset: eg. owner/group, quota, reservation, recordsize, snapshot frequency, share type, etc.

Point 2. What linux distro are you using? The commons ways to access SMB shares in linux are, (a) via an entry in /etc/fstab, (b) a mount command at the CLI or (c) using in-built functions in a typical desktop fie manager. These shouldn't be a problem. In general SMB will faster than NFS on a FreeNAS server that has no separate SLOG device.

Point 3. Is this a home network? Are you the only user, or will several people be accessing the same data on the FreeNAS server? The default settings of a Windows share in FreeNAS 11.2-U6 onwards do not allow "world" access, Setting the dataset owner/group to a specific account - e.g. "labounek" will restrict access to the authenticating user when a SMB shared FreeNAS dataset is accessed from linux.

Point4. The FreeNAS document is repeating advice for insecure NFS shares that do not use kerberos. It may not be convenient to use this method, but you can google that idea.

 

[René Labounek]

Ad 1. I agree that root and wheel settings is more proper and safer. I will try to change it and manage working NFS, if it will be needed. I know different partitions with different letters/mount points. But I do not see how can it make my life simpler and easier. Taking into account my other 5-10 simultaneously mounted commercial network HDDs, I do not see any reason why to split my "home" storage at multiple HDDs. Owner, group, permision settings I can do easialy directly at the server via ssh connection or via nfs if I would make it work and would have same table of users and groups over both machines. I do not see any reason how or why to use quota, reservation, etc. at the home NAS server. If there is some really crucial advantage which would make my data safer, I can not see it. Please let me know.

Ad 2. Distro: Ubuntu 18.04.3 LTS. I have tested connection via mount as suggested here: "Mount cifs Network Drive: write permissions and chown", it works that I can write new files or folders based on rules which I have set on the server, but I can not see the right settings at my local computer.
Local computer:

Code:

labounek@dendrit:/mnt$ sudo mount -t cifs -o username=${USER},password=${PASSWORD},uid=3547,gid=6478 //ganglium/ganglium-raid1 /mnt/ganglium-raid1
labounek@dendrit:/mnt$ ls -l ganglium-raid1/
celkem 0
drwxr-xr-x 2 labounek labosci 0 pro 29 14:12 fotky
drwxr-xr-x 2 labounek labosci 0 pro 29 13:53 iocage
drwxr-xr-x 2 labounek labosci 0 pro 29 01:41 Ivanka
drwxr-xr-x 2 labounek labosci 0 pro 29 14:10 labounek
labounek@dendrit:/mnt$

NAS server true reality:

Code:

labounek@ganglium:~$ ls -l /mnt/ganglium-raid1
total 34
drwxrwx---+ 4 labounek  labosci   4 Dec 29 14:12 fotky
drwxrwx---+ 9 root      wheel    10 Dec 29 13:53 iocage
drwxr-x---+ 2 Ivanka    labosci  10 Dec 29 01:41 Ivanka
drwxr-x---+ 4 labounek  labosci  15 Dec 29 14:10 labounek
labounek@ganglium:~$

Is there some way how to fix it? Otherwise I would still prefer working NFS communication. I will try to google it too...

Ad 3. Yes, home-network, public IP address is not planned for now. There will be 4 users accessing the same data or accessing user/sub-group specific data. E.g. Our kids will not be allowed to access some files, etc. I believe usernames and several different groups where sub-groups of users will belong will make the job.

Ad 4. If NFS would be still actual, I will try to make it work with root/wheel for the ganglium-raid1. But I am still unsuccessful. I do not think kerberos authentification is necessary for home non-commercial NAS server. If we would make the public IP address, I think restricted list of allowed MAC addreses enabled to connect to the server and BAN after 5 unsuccessful logins could be enough security bridge. I believe FreeNas is enabling to setup both. What do you think?

KrisBee, many thanks for the advices and feedback.

Kind regads,
Rene

 

[KrisBee]

Point 1. Perhaps there is a misunderstanding here. Using multiple datasets in a single pool is like having several partitions on one large hard drive, not creating multiple hard drives (HDD). I would encourage you to read about zfs datasets before you load data onto your pool, look at the “zfs primer” in the FreeNAS guide, the FreeBSD handbook https://www.freebsd.org/doc/handbook/zfs.html and google the subject.

Point 2. My previous comment about the relative speeds of SMB and NFS was about data transfers from client to FreeNAS server. FreeNAS, with zfs, supports NFSv4 ACLs which are almost the same as Windows ACLs. Hence the advice to manipulate windows shares from a windows client as shown in this video: https://youtu.be/RxggaE935PM

When a FreeNAS SMB share is mounted in linux the software maps those ACLs to standard linux permissions which are clearly not identical. What ends up on the FreeNAS server and whether your linux client can access the data as you wish is what is important.

Point 4. You really should be sharing one or more datasets, not the pool which is what you are doing by referencing /mnt/ganglium-raid1. Setting up kerberos is a non-trivial exercise, so is possibly over-kill for a home lan network. I suppose it all depends on your level of paranoia and what other security measure you have in place and access controls. As each dataset is its own filesystem, you have some additional control over access by using multiple dataset, as each requires a separate NFS share definition.

All this takes careful planning and possibly some experimentation to reach a solution that works you.