Главная » Linux

Nfs permissions denied linux

На чтение 11 мин Просмотров 1 Опубликовано
Содержание
  1. NFS mount attempts fail with «permission denied» or succeed initially but fail after 30 minutes
  2. Environment
  3. Situation
  4. Resolution
  5. Cause
  6. Additional Information
  7. Disclaimer
  8. unixforum.org
  9. mount.nfs: mount(2): Permission denied

NFS mount attempts fail with «permission denied» or succeed initially but fail after 30 minutes

This document (000020618) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15 SP3
SUSE Linux Enterprise Server 15 SP2
SUSE Linux Enterprise Server 15 SP1
SUSE Linux Enterprise Server 15 SP0

Situation

NFS v4 client mount attempts against a Linux NFS Server fail immediately with «permission denied».

NFS v3 client mount attempts against a Linux may fail immediately, or may succeed but after 30 minutes stop working, with «permission denied».

There are, of course, many reasons an NFS Server could return «permission denied,» but for this particular scenario, several unique factors and clues are present.

1. The possible difference in v3 behavior as described above.

2. When checking certain output at the Linux NFS Server machine, the following error may be seen:
conf_parse: last line non-terminated, ignored.

Places on the Linux NFS Server machine where this message have been noted include:
a. Output of «exportfs -v»
b. /var/log/messages
c. Output of «systemctl status nfs-server» (but not from «systemctl status nfsserver»)
d. Output of «journalctl»

3. After «permission denied» is given at the client machine, issuing the following command at the NFS Server machine:
cat /proc/net/rpc/auth.unix.ip/content

will show a line similar to:
nfsd 192.168.1.245 -no-domain-

It is the «-no-domain-» part of that line which is of unique interest here. This indicates that something has gone wrong with the way NFS clients are being trusted (allowed) to mount what the NFS Server is exporting.

4. When «permission denied» is received from the NFS Server, packet traces show that the RPC header (not NFS header) of the reply packet includes the following (as viewed from wireshark):
AUTH_ERROR (1)
bad crediential (seal broken) (1)

Resolution

The problem can be fixed at the NFS Server machine, either manually in configuration files or by updated code which avoids the problem.

1. To fix manually (recommended, even if code will also be updated):

The last line of certain NFS-related configuration files may be unterminated. In other words, the file does not end with a «new line» character. This is quite unusual, as most Linux based editors will automatically include a new line at the end of an ASCII file when it is typed up and saved, even if the user does not explicitly press after the final line. As such, it is probably best to correct this condition if it is found. Files where this condition may trigger this problem include:

/etc/nfs.conf.local #which may not exist, but (if it does) is the most likely source of the problem
/etc/nfs.conf
/etc/sysconfig/nfs

Edit those files. If, while editing the file, it is already possible to move down to a final empty line, then nothing needs to be changed. However, if the file ends at the right hand side of a non-empty line (even in a comment line) this can trigger the problem. After the last character of the last line, insert a new line by pressing the key. If using «vi», be sure to be in «insert mode» first.

Читайте также:  Run linux code on android

You could also check those files for new-line characters with the «od» command. For an example, see the «Additional Information» section below.

2. To fix this with updated code:

The «nfs-kernel-server» package needs to be updated. Incidentally, this package is built from a source code package named «nfs-utils,» so it is best to update the «nfs-client» package at the same time, as both are built from the «nfs-utils» source package.

On SLES 15 SP1 / SP2 / SP3, the fix was first supplied in nfs-kernel-server 2.1.1-10.21.1. For SP3, this is available in general maintenance updates. However, for SP1 and SP2 it is available only with LTSS or ESPOS entitlement.

On SLES 15 without any support pack, the fix was first supplied in nfs-kernel-server 2.1.1-6.17.1 (available only with LTSS or ESPOS entitlement).

Cause

Interestingly, the problem is only indirectly caused by the lack of line termination. When the lack of line termination is detected, the mountd (the mount daemon) sends a message to the logging daemon warning «conf_parse: last line non-terminated, ignored.» This message causes a socket to be opened to the logging daemon, and it is left open. When closeall() is subsequently called, the socket in closed but the logging library thinks it is still open. Later, this causes confusion and mountd ends up blocking while trying to read from something that isn’t what it thinks it is.

Upstream fix is
Commit 7fc4d064f951 («mountd: Initialize logging early.»)

In the upstream public project for nfs-utils, this fix first came in nfs-utils version 2.4.2. However, within SLES, it has been backported into the earlier versions listed above in the «Resolution» section.

Additional Information

Pursuant to the manual fix in the «Resolution» section above, it is possible to check for end-of-line characters more certainly and without opening the files in an editor. For example, the «od» command can be used. Consider a /etc/nfs.conf.local file which to the naked eye appears as the two following lines:

Using this command to view it:

od -cb nfs.conf.local
0000000 # E n d o f / e t c / n f
043 040 105 156 144 040 157 146 040 057 145 164 143 057 156 146
0000020 s . c o n f . l o c a l \n # # #
163 056 143 157 156 146 056 154 157 143 141 154 012 043 043 043
0000040 # # # # # # # # # # # # # # # #
043 043 043 043 043 043 043 043 043 043 043 043 043 043 043 043
0000060 # # # # # # # # #
043 043 043 043 043 043 043 043 043
0000071

In the od output above, the end of the file’s first line is designated with the «\n» symbol, aka «new line», aka value 012. That value may differ from 012 if other od options are used. The final line has no such character at the end, meaning it is missing the new line character and could trigger the problem.

Читайте также:  Просмотр камер hikvision linux

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented «AS IS» WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000020618
  • Creation Date: 16-Mar-2022
  • Modified Date:16-Mar-2022
    • SUSE Linux Enterprise Server

    For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

    Источник

    unixforum.org

    Привет.
    Бьюсь, который день. Весь инет облазил, кругом, по сути, пишут одно и то же. Не могу примонтировать директорию по nfs.

    Итак, что у меня есть:
    Сервер:
    debian lenny с внешним ip (светится в сеть)
    Клиент:
    debian lenny — установлен в качестве гостевой системы на virtualbox

    Пинг серверной машины на клиентской проходит успешно. Клиентская машина спокойно выходит в инет

    Задача: примонтировать експортируемую директорию сервера на клиентской машине

    Мои шаги:
    На сервере установил nfs-kernel-server nfs-common portmap
    На клиенте установил nfs-common portmap

    конфиги:
    /etc/hosts.deny
    здесь все закомментировано 

    # /etc/hosts.deny: list of hosts that are _not_ allowed to access the system. # See the manual pages hosts_access(5) and hosts_options(5). # # Example: ALL: some.host.name, .some.domain # ALL EXCEPT in.fingerd: other.host.name, .other.domain # # If you're going to protect the portmapper use the name "portmap" for the # daemon name. Remember that you can only use the keyword "ALL" and IP # addresses (NOT host or domain names) for the portmapper, as well as for # rpc.mountd (the NFS mount daemon). See portmap(8) and rpc.mountd(8) # for further information. # # The PARANOID wildcard matches any host whose name does not match its # address. # You may wish to enable this to ensure any programs that don't # validate looked up hostnames still leave understandable logs. In past # versions of Debian this has been the default. # ALL: PARANOID
    # /etc/hosts.allow: list of hosts that are allowed to access the system. # See the manual pages hosts_access(5) and hosts_options(5). # # Example: ALL: LOCAL @some_netgroup # ALL: .foobar.edu EXCEPT terminalserver.foobar.edu # # If you're going to protect the portmapper use the name "portmap" for the # daemon name. Remember that you can only use the keyword "ALL" and IP # addresses (NOT host or domain names) for the portmapper, as well as for # rpc.mountd (the NFS mount daemon). See portmap(8) and rpc.mountd(8) # for further information. # portmap:ALL lockd:ALL rquotad:ALL mountd:ALL statd:ALL
    # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). # # Example for NFSv2 and NFSv3: # /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) # # Example for NFSv4: # /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) # /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check) # /home/user/nfs *(ro,sync,no_root_squash,,subtree_check)

    * — разрешить всем ip адресам
    rw — чтение/запись
    sync — синхронный доступ
    subtree_check
    no_root_squash — запрещен доступ под root’ом

    #/etc/init.d/nfs-kernel-server restart

    вроде бы сервен настроен и экспортирует директорию /home/user/nfs

    Теперь на клиенте пытаюсь примонтировать удаленную директорию
    # mount server_ip:/home/user/nfs /home/user/server_dir
    на это получаю:
    mount.nfs: server_ip:/home/user/nfs failed, reason given by server: Permission denied
    В инете встречал, что такая ошибка встречается, если экспортируемые директории не правильно настроены в файле /etc/exports
    Вообщем, как правильно настроить.
    Да, еще хотел сказать, что клиентская машина хочет получить доступ к расшаренной папке на сервере через интернет, может это есть причина ошибки монтирования?

    Источник

    mount.nfs: mount(2): Permission denied

    I have a external harddrive mounted in /media/hdd and I want to share it with another client, specifically in the folder /mnt/archive. I want to save some files from the client into this harddrive the steps I have follow are in https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nfs-mount-on-ubuntu-16-04 The IPs are the following: IP Server: 69.112.130.223 IP Client: 69.112.130.130 I have tried this command:

    sudo mount -v 69.112.130.223:/media/proton /mnt/archive 
     mount: no type was given - I'll assume nfs because of the colon mount.nfs: timeout set for Mon Oct 29 19:08:13 2018 mount.nfs: trying text-based options 'vers=4,addr=69.112.130.223,clientaddr=69.112.130.130' mount.nfs: mount(2): Permission denied mount.nfs: access denied by server while mounting 69.112.130.223:/media/proton 
    # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). /media/proton 69.112.130.130(rw,sync,no_root_squash,no_subtree_check) 
    rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 57154 mountd 100005 1 tcp 48817 mountd 100005 2 udp 50301 mountd 100005 2 tcp 52587 mountd 100005 3 udp 52789 mountd 100005 3 tcp 57659 mountd 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 3 tcp 2049 100003 3 udp 2049 nfs 100227 3 udp 2049 100021 1 udp 44354 nlockmgr 100021 3 udp 44354 nlockmgr 100021 4 udp 44354 nlockmgr 100021 1 tcp 39665 nlockmgr 100021 3 tcp 39665 nlockmgr 100021 4 tcp 39665 nlockmgr 
    rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 34223 status 100024 1 tcp 36796 status 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 2 tcp 2049 100227 3 tcp 2049 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100227 2 udp 2049 100227 3 udp 2049 100021 1 udp 2002 nlockmgr 100021 3 udp 2002 nlockmgr 100021 4 udp 2002 nlockmgr 100021 1 tcp 2001 nlockmgr 100021 3 tcp 2001 nlockmgr 100021 4 tcp 2001 nlockmgr 100005 1 udp 2000 mountd 100005 1 tcp 2000 mountd 100005 2 udp 2000 mountd 100005 2 tcp 2000 mountd 100005 3 udp 2000 mountd 100005 3 tcp 2000 mountd 
     rpcbind mountd nfsd statd lockd rquotad : 69.112.130.130

    I am pretty sure that the error has to be something related to the server side and how the permissions are configured but I have looked everywhere and I dont find a solution I can ping and ssh from client and server side and I can mount the harddrive using ssfhs but I want to use nfs

    Источник

Оцените статью
© 2023 Posetke
Adblock
detector