在虚拟机内部，主机地址是10.0.2.2，本地地址是10.0.2.15。 （VirtualBox的）。 这将在主机端转换为127.0.0.1。 连接： sudo mount -vvvt nfs4 -o clientaddr=127.0.0.1 10.0.2.2:/srv /mnt 我指定clientaddr，因为我想这个问题可能是由于地址不匹配，但它不会改变任何东西。 几分钟后，客户端返回通常的权限拒绝消息，服务器拒绝访问。 在服务器端，我运行 # rpc.mountd -d all -F # rpc.idmapd -vvvf # rpc.nfsd -d 我使用systemd，所以我也监视日志的任何输出。 当我发出安装请求时，以下内容在networking中可见： reply ERR 20: Auth Bogus Credentials (seal broken) 但日志（除rpc.nfsd之外）或rpc.mountd或rpc.idmapd的输出中，除了某些启动消息外，不会显示任何内容。 实际上，在rpc.mountd的情况下，偶尔会得到以下结果： rpc.mountd: auth_unix_ip: inbuf 'nfsd 127.0.0.1' rpc.mountd: auth_unix_ip: client (nil) 'DEFAULT' 据我所知（请纠正我！）没有其他来源的信息NFS的function，也没有configuration涉及。 我已经为每个命令指定了冗长的模式，所以我对如何诊断这个问题感到不知所措。 我假设这是我的导出文件的问题，如下所示： /srv 127.0.0.1(rw,sync,no_subtree_check,no_root_squash) 但我宁愿从系统得到一些反馈，告诉我哪里出了问题，而不是通过反复试验来摆弄出口文件。 那么，有没有人知道我在哪里可以find更多关于发生了什么？ […]
我有一个由ftp:users拥有的文件夹。 我想导出这个文件夹，并将所有的请求映射到ftp用户，其ID为107.在/etc/exports我有以下内容： /media/other 10.1.1.10(rw,sync,all_squash,no_subtree_check,anonuid=107) 这按预期工作。 在客户端，我想映射这些匿名请求到不同的用户，所以在/etc/idmapd.conf我有这样的： Nobody-User = nfsanon Nobody-Group = nfsanon 但是，当挂载NFSv4时，所有内容都由nobody:users 。 它正确地映射了组（它也存在于客户端上），但是客户端上不存在的ftp用户映射到idmapd.conf nobody而不是Nobody-User 。 为了试图理解为什么会发生这种情况，我打开了详细信息，并将其插入客户端日志中 。 一次安装尝试产生以下内容： nfsidmap[8610]: key: 0x28bf0a94 type: uid value: [email protected] timeout 600 nfsidmap[8610]: nfs4_name_to_uid: calling nsswitch->name_to_uid nfsidmap[8610]: nss_getpwnam: name '[email protected]' domain 'dom.ain': resulting localname 'root' nfsidmap[8610]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 nfsidmap[8610]: nfs4_name_to_uid: final return value is 0 nfsidmap[8612]: […]
简短的问题描述 这个问题是关于NFSv4中的id映射出错的。 NFS服务器：Synology DS，DSM 5.2。 客户端：常规FC22机器，它自动挂载为上面导出的文件夹之一。 这两台机器都注册了一个freeIPA域的客户端，因此使用freeIPA服务器作为DNS和LDAP服务器。 当LDAP用户login客户端时，它会find已安装的文件夹。 所以挂载工作。 但是，文件的所有权被映射为nobody:nobody 。 我知道这个“没有人问题”并不是什么新东西，但是迄今为止我find的解决scheme都没有解决这个问题。 LDAP用户login和文件触摸 $ ssh ldapuser1@client1 ldapuser1@client1's password: -bash-4.3$ id uid=1172000004(ldapuser1) gid=1172000004(ldapuser1) groups=1172000004(ldapuser1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ldapuser1可以正确login并具有uid 1172000004。 -bash-4.3$ pwd /home/ldapuser1 -bash-4.3$ ls -lan total 8 drwxrwxrwx. 2 1172000004 1172000004 4096 18 aug 17:34 . drwxr-xr-x. 3 0 0 0 18 aug 18:33 .. LDAP用户在其主目录中正确着陆，先创build并分配给他。 但是任何新文件都会得到错误的所有权： -bash-4.3$ […]
我一直使用CIFS进行networking连接的时间最长，而且我想使用NFS进行Linux到Linux的文件分发。 我有一个共享驱动器，我已经设置了一个粘性组，看起来工作正常时通过NFS挂载，除非root正在写入。 所以在文件服务器上有一个名为media的目录，我已经使用ACL setfacl -d -mu::rwx,g::rwx,o::rx Media来执行，所以它看起来像这样： drwsrwsrwx+ 16 chrishunter users 4096 Sep 25 06:10 Media 并执行行动按预期工作： chrishunter@server:/media/disk1/Media$ touch file chrishunter@server:/media/disk1/Media$ sudo touch file2 [sudo] password for chrishunter: chrishunter@server:/media/disk1/Media$ sudo su root@server:/media/Media# touch file3 root@server:/media/Media# ls -ltra file* -rw-rw-r– 1 chrishunter users 0 Sep 26 05:51 file -rw-rw-r– 1 root users 0 Sep 26 05:51 […]
在过去的两天中，我尝试将我的光盘备份到一个NFS共享。 但过了一阵子，rsync挂了。 每次在同一个文件。 但是，如果我排除文件，它会挂断下一个文件。 所以至less不是直接导致问题的文件。 如果我用strace来执行进程，我会看到一个ERESTARTNOHEAD错误和一些超时。 但我认为这些超时并不直接与问题直接相关，因为它们出现在实际的错误之前。 看来，ERESTARTNOHEAD是问题，但我无法find这个错误很多。 这个系统是一个Debian老式的NFS服务器和一个Ubuntu 15.10作为客户端 该命令是：rsync -av / home / myuser / nfs / backup strace的输出：
NFS服务器：CentOS7.1（内核3.10.0-229，nfs-utils 1.3.0） 一些客户端使用NFSv3的Ubuntu Precise（12.04）…他们工作正常。 有问题的客户端使用NFSv4.1（或NFSv4.0）运行CentOS7.1。 他们大多数时间，事情工作正常。 但是有时候，写一个文件会导致15秒的超时。 这些是小文件（<10KiB）。 15秒后，写入完成，文件具有正确的内容。 最明显的时间是用vi保存文件。 它只发生在大约5％的时间（但是因为它非常令人沮丧，感觉比实际情况更频繁）。 今天发生在数百个文件（每个2KiB – 5KiB）上运行rsync时。 我能够在rsync过程中运行strace，并且发现它正在发生超过50％的时间。 # sudo strace -ttt -T -p 14186 Process 14186 attached 1452694932.030892 select(9, [8], [], NULL, {55, 59875}) = 1 (in [8], left {44, 963900}) <10.096109> 1452694942.127262 read(8, "\4\0\0k\10\3\0\0", 8184) = 8 <0.000038> 1452694942.127378 select(9, [8], [], NULL, {60, 0}) = […]
挂载多个共享时获取意外的行为。 NFS服务器 $ -> cd /mnt/raid/nas && ls -lZa drwxrwxr-x. nas filer unconfined_u:object_r:file_t:s0 file drwxrwxr-x. nas filer unconfined_u:object_r:file_t:s0 repo $ -> cat /etc/exports /mnt/raid/nas 10.1.0.0/18(rw,fsid=0,sync) /mnt/raid/nas/repo 10.1.0.0/18(rw,all_squash,sync,no_subtree_check,anonuid=501,anongid=503) /mnt/raid/nas/file/perm 10.1.0.0/18(rw,all_squash,sync,no_subtree_check,anonuid=501,anongid=503) $ -> id nas && id filer uid=501(nas) gid=501(nas) groups=501(nas) uid=502(filer) gid=503(filer) groups=503(filer) NFS客户端 $ -> id nas && id filer uid=501(nas) gid=501(nas) groups=501(nas) uid=502(filer) gid=503(filer) […]
据我所知，并行NFS（pNFS）有三种types：文件布局，块布局和对象布局。 每种types的优点和缺点是什么？
由于在我的NFS客户端和NFS服务器上最近进行的Linux内核升级（在Debian Wheezy上是3.2.78），我看到从客户端到服务器的nfs_lookup请求的数量增加很多（10到20倍）。 这对运行在我的NFS客户端上的应用程序（apache + php-fpm）造成巨大的性能下降。 什么可能导致nfs_lookup这么高的增长？ 正常运行1小时后，在其中一个客户mountstats –nfs上输出mountstats –nfs如下： Stats for ruchbah.nfs://membres mounted on /srv/membres: NFS mount options: rw,vers=4,rsize=1048576,wsize=1048576,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.74.13,minorversion=0,local_lock=none NFS server capabilities: caps=0x7fff,wtmult=512,dtsize=32768,bsize=0,namlen=255 NFSv4 capability flags: bm0=0xfdffbfff,bm1=0xf9be3e,acl=0x3 NFS security flavor: 1 pseudoflavor: 0 Cache events: data cache invalidated 1231 times attribute cache invalidated 23693734 times inodes synced 1790 times VFS calls: VFS requested 46296214 inode […]
我已经build立了一个专门的网页开发学习实用的房间。 用户帐户由Samba 4 ADpipe理，用户文件存储在中央NFS服务器上，导出由Kerberos进行证实。 一切正常： 用户可以通过Kerberos进行身份validation（并在login时收到一张票） 家庭使用NFS4（sec = krb5） 权利正确地适用于所有域用户 但是，我需要在每个客户端上安装一个localhost-only的服务器（用php和其他东西），并激活userdir。 我爬了互联网，但似乎只有极less数人与我处于同一个configuration。 我试过所有我发现像创build一个SPN和一个Apache专用密钥表： # samba-tool spn add HTTP/client1.domain client1$ # samba-tool domain exportkeytab httpclient1.keytab –principal=HTTP/client1.domain 并在client1上的/ etc / apache2中导出这个生成的keytab，但是如果我尝试在此keytab上执行kinit：＃kinit -k -t /etc/apache2/client1http.keytab HTTP / client1.domain kinit：Client“HTTP / client .domain @ REALM“在获取初始凭据时未在Kerberos数据库中find keytab似乎是正确的： # klist -kt /etc/apache2/client1http.keytab KVBO Timestamp Principal —- ——————- —————————- 4 29/07/2016 16:12:38 […]