Mounting NFS share from Synology NAS

[Christian Britz]

Hello,

I am playing with NFS on my home network for the first time and I have
some difficulties/questions.

The server is a Synology NAS, it is based on Linux, supports NFS4 and
gets configured by a web interface.
The NAS offers a Kerberos authentification for NFS but I did not
configure this. Instead, something called AUTH_SYS is enabled. Only one
specific host is allowed to access the share.


This is my entry in /etc/fstab:
diskstation:/volume1/Medien /Daten nfs
nfsvers=4,rw,x-systemd.automount,noauto 0 0

Mounting only works as root, I guess this is expected without further
configuration.

1. Security: It seems that the only security check is the check for my
IP adress. Is it possible to achieve more without dealing with Kerberos?

2. Accessing the mounted share with my personal user: The access rights
for /Daten look right, the user on the NAS has the same name as the user
on my machine. But:

ls -ahl /Daten/
ls: cannot open directory '/Daten/': Permission denied

sudo ls -ahl /Daten/
[sudo] password for xyz:
total 340K
drwxrwxrwx 14 xyz root 4.0K Jan 30 21:31 .
drwxr-xr-x 19 root root 4.0K Jan 24 09:58 ..
drwxrwxrwx 5 xyz users 4.0K Jan 30 21:31 Directory1
drwxrwxrwx 4 xyz users 4.0K Aug 10 10:28 Directory2

Why can't user xyz access the mountpoint?

Thank you for your support.

Regards,
Christian

[Henning Follmann]

On Tue, Feb 01, 2022 at 04:32:57PM +0100, Christian Britz wrote:
> Hello,
>
> I am playing with NFS on my home network for the first time and I have
> some difficulties/questions.
>
> The server is a Synology NAS, it is based on Linux, supports NFS4 and
> gets configured by a web interface.
> The NAS offers a Kerberos authentification for NFS but I did not
> configure this. Instead, something called AUTH_SYS is enabled. Only one
> specific host is allowed to access the share.
>
>
> This is my entry in /etc/fstab:
> diskstation:/volume1/Medien /Daten nfs
> nfsvers=4,rw,x-systemd.automount,noauto 0 0
>
> Mounting only works as root, I guess this is expected without further
> configuration.
>
> 1. Security: It seems that the only security check is the check for my
> IP adress. Is it possible to achieve more without dealing with Kerberos?
>
> 2. Accessing the mounted share with my personal user: The access rights
> for /Daten look right, the user on the NAS has the same name as the user
> on my machine. But:

And how about the userId?
The username does not mean anything. The access control is
based on Id.

>
> ls -ahl /Daten/
> ls: cannot open directory '/Daten/': Permission denied
>
> sudo ls -ahl /Daten/
> [sudo] password for xyz:
> total 340K
> drwxrwxrwx 14 xyz root 4.0K Jan 30 21:31 .
> drwxr-xr-x 19 root root 4.0K Jan 24 09:58 ..
> drwxrwxrwx 5 xyz users 4.0K Jan 30 21:31 Directory1
> drwxrwxrwx 4 xyz users 4.0K Aug 10 10:28 Directory2
>
> Why can't user xyz access the mountpoint?
>
> Thank you for your support.
>
> Regards,
> Christian
>

-H

--
Henning Follmann | hfol...@itcfollmann.com

[Bob Weber]

On 2/1/22 10:32, Christian Britz wrote:

This is my entry in /etc/fstab:
diskstation:/volume1/Medien /Daten nfs
nfsvers=4,rw,x-systemd.automount,noauto 0 0

Have you tried the user option in fstab? 

user - Permit any user to mount the filesystem.

nouser - Only permit root to mount the filesystem. This is also a default setting.

--


...Bob

[Greg Wooledge]

On Tue, Feb 01, 2022 at 11:28:55AM -0500, Henning Follmann wrote:
> On Tue, Feb 01, 2022 at 04:32:57PM +0100, Christian Britz wrote:
> > This is my entry in /etc/fstab:
> > diskstation:/volume1/Medien /Daten nfs
> > nfsvers=4,rw,x-systemd.automount,noauto 0 0
> >
> > Mounting only works as root, I guess this is expected without further
> > configuration.
> >
> > 1. Security: It seems that the only security check is the check for my
> > IP adress. Is it possible to achieve more without dealing with Kerberos?
> >
> > 2. Accessing the mounted share with my personal user: The access rights
> > for /Daten look right, the user on the NAS has the same name as the user
> > on my machine. But:
>
> And how about the userId?
> The username does not mean anything. The access control is
> based on Id.

I'm unclear on how NFS v4 works. Everything I've read about it in the
past says that you have to set up a user mapping, which is shared by
the client and the server. And that this is *not* optional, and *is*
exactly as much of a pain as it sounds.

I'm looking at <https://help.ubuntu.com/community/NFSv4Howto> for example
and there's discussion back and forth on the page about how the user
mapping is not working as expected, and try this and that, and see this
bug....

I've never actually used NFS v4 myself. In fact, at work I have to go out
of my way to *prevent* it from being used, because some of the NFS servers
to which I connect (which are not under my control) don't support it.

The comment about the access being based on UID is certainly true for
NFS v3, though. NFS v3 ("regular, traditional NFS") controls mounting
options by the host's IP address, and controls file system access by
UID and GID. There may be some way to circumvent that, but I've never
done it. I just make sure the UIDs and GIDs match, the way you're
supposed to.

For a home network, I can't really imagine a need to go through all of
the NFS v4 hoops. I would just use NFS v3 with synchronized UIDs.

[Tixy]

On Tue, 2022-02-01 at 11:43 -0500, Greg Wooledge wrote:
[...]

> I'm unclear on how NFS v4 works. Everything I've read about it in the
> past says that you have to set up a user mapping, which is shared by
> the client and the server. And that this is *not* optional, and *is*
> exactly as much of a pain as it sounds.
>
> I'm looking at <https://help.ubuntu.com/community/NFSv4Howto> for example
> and there's discussion back and forth on the page about how the user
> mapping is not working as expected, and try this and that, and see this
> bug....
>
> I've never actually used NFS v4 myself. In fact, at work I have to go out
> of my way to *prevent* it from being used, because some of the NFS servers
> to which I connect (which are not under my control) don't support it.
>
> The comment about the access being based on UID is certainly true for
> NFS v3, though. NFS v3 ("regular, traditional NFS") controls mounting
> options by the host's IP address, and controls file system access by
> UID and GID. There may be some way to circumvent that, but I've never
> done it. I just make sure the UIDs and GIDs match, the way you're
> supposed to.
>
> For a home network, I can't really imagine a need to go through all of
> the NFS v4 hoops. I would just use NFS v3 with synchronized UIDs.

Perhaps because I didn't know better, but I used NFSv4 since first
setting up my home network. My install notes for my clients just
have...

Edit /etc/default/nfs-common to have

NEED_IDMAPD=yes

Edit /etc/idmapd.conf, make sure these aren't commented out or missing...

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs # before jessie this was /var/lib/nfs/rpc_pipefs

Presumably that's the voodoo I found on the internet when I set things
up many years ago. I do have all my UIDs and GUIs matching across all
machines at home. Everything works seamlessly here. (On the server the
exports have option no_root_squash, the latter lets root use NFS
filesystem too.)

--
Tixy

[Christian Britz]

This works, one step further! :-)

[Christian Britz]

On 2022-02-01 17:28 UTC+0100, Henning Follmann wrote:
> On Tue, Feb 01, 2022 at 04:32:57PM +0100, Christian Britz wrote:
>> 2. Accessing the mounted share with my personal user: The access rights
>> for /Daten look right, the user on the NAS has the same name as the user
>> on my machine. But:
>
> And how about the userId?
> The username does not mean anything. The access control is
> based on Id.

Thank you, that was the right hint, the solution to get it work (with
NFS4 support) with IP based "security" was:

1. Recreate the user and group on the NAS web interface with the same
names as on my localhost.
2. Assign the right group via SSH to the user on the NAS.
3. chown -R the files on the NAS to the new user and group.
4. Change UID and GID on my localhost to match the UID and GID on the
NAS (I read somewhere that the Synology crap has problems if you change
UID and GID on the server).
5. Fix ownership of files on localhost
=> Works!

Drawback 1, compared to my previous SMB mount method: The NAS internal
sub-directories named "@eaDir" are visible when accessing the share via
NFS. Workaround: Deleting them. Should be relatively safe according to
the Web. In the worst case, they get recreated.

Drawback 2: Security is only relying on the client IP. This would
probably be not acceptable, if I were not the only user on my network.
Is my assumption right, that I would have to setup a Kerberos server to
achieve real security?

Big advantage, compared to my previous SMB mount method: the modified
timestamp is finally shown correctly. This didn't seem to work correctly
with SMB.

Thank you all.

[Anssi Saari]

Greg Wooledge <gr...@wooledge.org> writes:

> I'm unclear on how NFS v4 works. Everything I've read about it in the
> past says that you have to set up a user mapping, which is shared by
> the client and the server. And that this is *not* optional, and *is*
> exactly as much of a pain as it sounds.

I've never done that, as far as I remember. NFS (NFSv4, these days)
mounts in my home network use autofs but I haven't done anything there
either specifically for NFS of any verstion. I remember there was some
weirdness at some point with NFSv4 and I didn't bother with it much. I
had maybe two computers back then so not much of network. But over the
years my NFS mounts just became NFSv4.

Access for me is by UID. Service is by the kernel driver or in the case
of zfs, the NFS service it provides. I've thought about setting up
Kerberos but haven't gotten around to it. One thing is, I don't know if
Kerberos would work with the NFS service zfs provides? No big deal
either way though.

> I'm looking at <https://help.ubuntu.com/community/NFSv4Howto> for example
> and there's discussion back and forth on the page about how the user
> mapping is not working as expected, and try this and that, and see this
> bug....

It's a wiki by random people. Last updated in 2017, looks like. Did you
think it has particular relevance to Debian or NFS today?

[gene heskett]

On Wednesday, February 2, 2022 6:49:38 AM EST Anssi Saari wrote:
> Greg Wooledge <gr...@wooledge.org> writes:
> > I'm unclear on how NFS v4 works. Everything I've read about it in
> > the
> > past says that you have to set up a user mapping, which is shared by
> > the client and the server. And that this is *not* optional, and *is*
> > exactly as much of a pain as it sounds.
>
> I've never done that, as far as I remember. NFS (NFSv4, these days)
> mounts in my home network use autofs but I haven't done anything there
> either specifically for NFS of any verstion. I remember there was some
> weirdness at some point with NFSv4 and I didn't bother with it much. I
> had maybe two computers back then so not much of network. But over the
> years my NFS mounts just became NFSv4.

Sounds like how my network grew, with more cnc'd machines added. But I
was never able the make MFSv4 Just Work for anything for more than the
next reboot of one of the machines. Then I discovered sshfs which Just
Does anything the user can do, it does not allow root access, but since I
am the same user number on all machines, I just put whatever needs root
in a users tmp dir then ssh login to that machine, become root and then
put the file wherever it needs to go. I can do whatever needs done, to
any of my machines, currently 7, from a comfy office chair.

> Access for me is by UID. Service is by the kernel driver or in the case
> of zfs, the NFS service it provides. I've thought about setting up
> Kerberos but haven't gotten around to it. One thing is, I don't know
> if Kerberos would work with the NFS service zfs provides? No big deal
> either way though.
>
> > I'm looking at <https://help.ubuntu.com/community/NFSv4Howto> for
> > example and there's discussion back and forth on the page about how
> > the user mapping is not working as expected, and try this and that,
> > and see this bug....
>
> It's a wiki by random people. Last updated in 2017, looks like. Did you
> think it has particular relevance to Debian or NFS today?
>

> .
Stay well all.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Christian Britz]

On 2022-02-02 02:01 UTC+0100, Christian Britz wrote:

> Thank you, that was the right hint, the solution to get it work (with
> NFS4 support) with IP based "security" was:

[...]

> Is my assumption right, that I would have to setup a Kerberos server to
> achieve real security?

I am thinking about going the Kerberos path indeed. Sometimes there are
guests on my LAN and I think it is a good opportunity to broaden my
knowledge.

Unfortunately Synology does not ship a Kerberos server and my DS115j
model is not capable of running docker. In the long term, I might
replace the NAS.

Now I am thinking about running the Kerberos server components on my
client. Is it possible at all to run server and client on the same
network interface?

Any hints would be welcome.

[Bob Weber]

On 2/2/22 07:36, gene heskett wrote:

Sounds like how my network grew, with more cnc'd machines added. But I 
was never able the make MFSv4 Just Work for anything for more than the 
next reboot of one of the machines.  Then I discovered sshfs which Just 
Does anything the user can do, it does not allow root access, but since I 
am the same user number on all machines, I just put whatever needs root 
in a users tmp dir then ssh login to that machine, become root and then 
put the file wherever it needs to go. I can do whatever needs done, to 
any of my machines, currently 7, from a comfy office chair.
Stay well all.

Cheers, Gene Heskett.

I second the sshfs approach.   I use it between several Debian servers and have been happy with the results.  Once setup in the fstab a click in a GUI or mount command on the cli mounts the remote server on a directory specified in the fstab.

A sample of a line in the fstab (check docs for more options):

sshfs#ro...@172.16.0.xxx:/   /mnt/deb-test  fuse  user,noauto,rw    0       0

The user at the remote system is root in this example.  Not a good idea unless you are the only one who can login to your system.  I use ssh keys always.  If they are created without a password sshfs won't ask for one when it is mounted (I need this for my backup system Backuppc).  I even use sshfs to access a Digital Ocean droplet I have over the internet.

The current NAS you have might work with sshfs if their ssh server supports SFTP.

--


...Bob

[Christian Britz]

On 02.02.22 23:06, Bob Weber wrote:
> On 2/2/22 07:36, gene heskett wrote:
>>
>> Sounds like how my network grew, with more cnc'd machines added. But I
>> was never able the make MFSv4 Just Work for anything for more than the
>> next reboot of one of the machines. Then I discovered sshfs which Just
>> Does anything the user can do, it does not allow root access, but since I
>> am the same user number on all machines, I just put whatever needs root
>> in a users tmp dir then ssh login to that machine, become root and then
>> put the file wherever it needs to go. I can do whatever needs done, to
>> any of my machines, currently 7, from a comfy office chair.
>> Stay well all.
>>
>> Cheers, Gene Heskett.
>
> I second the sshfs approach.   I use it between several Debian servers
> and have been happy with the results.  Once setup in the fstab a click
> in a GUI or mount command on the cli mounts the remote server on a
> directory specified in the fstab.
>
> A sample of a line in the fstab (check docs for more options):

[...]

Thanks Gene and Bob, I didn't think of sshfs, although I have used it on
other occasions in the past. It works perfectly and I have disabled the
other file share options on the NAS. The performance feels even better
compared to SMB and NFS.

In the long term, I will setup my own Debian based home server, there
are many usefull suggestions in the other thread.

[Tixy]

On Wed, 2022-02-02 at 17:06 -0500, Bob Weber wrote:
[...]

> I second the sshfs approach.   I use it between several Debian servers and have
> been happy with the results.  Once setup in the fstab a click in a GUI or mount
> command on the cli mounts the remote server on a directory specified in the fstab.

If you use a GUI, you can also have gvfs installed (default in some
desktops) and then in your file manager just use the directory path
like ssh://user@host/ with user being optional if you want the current
user. You can add bookmarks in your filemanager for the paths you use
frequently.

I use this for quick access for copying and editing files on other
machines. For proper automated backup and bulk storage I use NFS on a
NAS/router box (an ARM based computer running Debian).

--
Tixy

[Christian Britz]

I use x-systemd.automount option in the fstab and have the path
available in my file manager.

[Andrei POPESCU]

On Mi, 02 feb 22, 13:49:38, Anssi Saari wrote:
> Greg Wooledge <gr...@wooledge.org> writes:
>
> > I'm unclear on how NFS v4 works. Everything I've read about it in the
> > past says that you have to set up a user mapping, which is shared by
> > the client and the server. And that this is *not* optional, and *is*
> > exactly as much of a pain as it sounds.
>
> I've never done that, as far as I remember. NFS (NFSv4, these days)
> mounts in my home network use autofs but I haven't done anything there
> either specifically for NFS of any verstion. I remember there was some
> weirdness at some point with NFSv4 and I didn't bother with it much. I
> had maybe two computers back then so not much of network. But over the
> years my NFS mounts just became NFSv4.

Are you sure you're actually using NFSv4? (check 'mount | grep nfs').

In my experience in order to make NFSv4 work it's necessary to configure
a "root" share with fsid=0 or something like that and mount
the actual shares using a path relative to it (my NFS "server" is
currently down, so I can't check exactly what I did).

> Access for me is by UID. Service is by the kernel driver or in the case
> of zfs, the NFS service it provides. I've thought about setting up
> Kerberos but haven't gotten around to it. One thing is, I don't know if
> Kerberos would work with the NFS service zfs provides? No big deal
> either way though.

As far as I know ZFS is using the kernel NFS server, it's just providing
a convenient method to share / unshare so it's not necessary to mess
with /etc/exports if all your shares are ZFS data sets.

(zfs-utils Suggests: nfs-kernel-server and
https://wiki.debian.org/ZFS#NFS_shares implies the same)

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Anssi Saari]

Andrei POPESCU <andreim...@gmail.com> writes:

> Are you sure you're actually using NFSv4? (check 'mount | grep nfs').

Yes I'm sure. It's all host on path type nfs4 and in options also
vers=4.2.

Also the bog standard auto.net these days has code to mount using NFSv4.

> In my experience in order to make NFSv4 work it's necessary to configure
> a "root" share with fsid=0 or something like that and mount
> the actual shares using a path relative to it (my NFS "server" is
> currently down, so I can't check exactly what I did).

That's the weirdness I meant. But it's not true, these days and hasn't
been for years. Or maybe it's hidden? But I can do, for example:

# mount zippy:/tmp /mnt/foo
# mount|grep zip
zippy:/tmp on /mnt/foo type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.119,local_lock=none,addr=10.0.2.126)

I don't have anything about that in fstab. This is actually a tmpfs
mount where I have fsid=something in /etc/exports but I don't know if
that's required today. zfs mounts the same way from zippy and I don't
have any fsid stuff there. Of course it could be handled automatically.

Autofs mounts a little differently, this is like the old way:

zippy:/ on /net/zippy type nfs4 (rw,nosuid,nodev,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.119,local_lock=none,addr=10.0.2.126)
zippy:/tmp on /net/zippy/tmp type nfs4 (rw,nosuid,nodev,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.119,local_lock=none,addr=10.0.2.126)

> As far as I know ZFS is using the kernel NFS server, it's just providing
> a convenient method to share / unshare so it's not necessary to mess
> with /etc/exports if all your shares are ZFS data sets.

Good to know.