<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.nfsv4">
    <title>gmane.linux.nfsv4</title>
    <link>http://blog.gmane.org/gmane.linux.nfsv4</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11714"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11703"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11699"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11696"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11694"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11693"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11687"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11685"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11666"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11660"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11653"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11635"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11634"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11631"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11627"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11621"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11620"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11595"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11592"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.nfsv4/11585"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11714">
    <title>krb5 authentication error with nfs client 1.2.x</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11714</link>
    <description>&lt;pre&gt;Hello,

We are working on a problem here what is getting bigger. I will explain.

Our clients are using SLED 11. If they upgrade to sp1, they get a newer 
nfs client.

Client before update : nfs-client-1.1.3-18.17
Client after update : nfs-client-1.2.1-2.6.6

We are using krb5 authentication with an active directory. The nfs mount 
we are trying to make is on a netapp nashead.

The scenario is as followes. The client works as expected. When you ONLY 
upgrade the nfsclient package, we get an error :

mount /mnt/nfs/
mount.nfs4: access denied by server while mounting srvxxx:/vol/vol1/target

I have enabled logging on the rpcgssd :

Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: Full hostname for 
'srvxxx.domain.net' is 'srvxxx.domain.net'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: Full hostname for 
'server.domain.net' is 'server.domain.net'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: Key table entry not found 
while getting keytab entry for 'root
/server.domain.net&amp;lt; at &amp;gt;DOMAIN.NET'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14&lt;/pre&gt;</description>
    <dc:creator>Richard Smits</dc:creator>
    <dc:date>2010-08-31T14:49:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11703">
    <title>[RFC][PATCH] nfs4: set exception-&gt;state before callingnfs4_handle_exception() for locks</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11703</link>
    <description>&lt;pre&gt;At the latest kernel, it is calling nfs4_handle_exception() without 
setting exception-&amp;gt;state for locks. That cause client can't get lock 
success when new_lock_owner != 0.

nfs4_recovery_handle_error() also be called after nfs4_proc_renew, 
but claim OPEN proc always after RENEW proc. Maybe the function 
nfs4_state_end_reclaim_reboot() shouldn't be called when client 
get a NFS4ERR_STALE_CLIENTID error.

This patch sets exception-&amp;gt;state before calling nfs4_handle_exception()
and also modifies nfs4_recovery_handle_error().

Signed-off-by: Mi Jinlong &amp;lt;mijinlong&amp;lt; at &amp;gt;cn.fujitsu.com&amp;gt;

---
 fs/nfs/nfs4proc.c  |   12 +++++++++---
 fs/nfs/nfs4state.c |    4 ++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 089da5b..a2f56bc 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -4233,7 +4233,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int _nfs4_do_setlk(struct nfs4_state *state, int cmd, struct file_lock *f
 static int nfs4_lock_reclaim(struct nfs4_state *state, struct file_lock *reque&lt;/pre&gt;</description>
    <dc:creator>Mi Jinlong</dc:creator>
    <dc:date>2010-08-24T09:36:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11699">
    <title>Can create and delete but not overwrite</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11699</link>
    <description>&lt;pre&gt;I have a strange problem with Kerberos security and NFVv4.

I have two servers, one running RHEL 4 (kernel 2.6.9-89.0.25.ELsmp) and 
the other RHEL 5 (2.6.18-194.3.1.el5).  Clients running either OS work 
fine.

I have one user who is using Ubuntu (9.04 Jaunty; the kernel is 
2.6.28-19-generic #61-Ubuntu).  On that machine, he can access filesystems 
on the RHEL 5 server fine. Using filesystems mounted from the RHEL 4 
server, authenticated users can create and write files, but they cannot 
write to an existing file. SO, for example,

echo foo &amp;gt;foo

works, but a subsequent

echo foo &amp;gt;foo

says "Input/Output Error".

Any ideas?

&lt;/pre&gt;</description>
    <dc:creator>Steve Gaarder</dc:creator>
    <dc:date>2010-08-13T20:47:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11696">
    <title>就知道中秋节你会被铺天盖地的短信包围，英明的乙辉缇腿米８？绻，闪过卖茶叶蛋的老太太，钻进你的耳朵：祝中秋炖郑</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11696</link>
    <description>&lt;pre&gt;_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4&lt;/pre&gt;</description>
    <dc:creator>carrierebouvy</dc:creator>
    <dc:date>2010-08-10T21:46:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11694">
    <title>&lt;AD&gt;办公技能</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11694</link>
    <description>&lt;pre&gt;您   好：


        我司将于2010年8月13-14日 上 海 、8月20-21日  深 圳 、8月27-28日  北 京 三地举办:

《 企业白领核心办公技能（PPT+Excel）高级应用v3.0 》公开课！由企业信息化领域资深专家，

微软认证专家、IPMA认证项目经理、经济分析师、国际职业讲师协会认证讲师----陈 剑 先生主讲！

详细内容请来电咨询或发邮件至：baoming01&amp;lt; at &amp;gt;126.com 索取！　（来信请注明课程名称！）谢谢！ 


咨*询*电*话：0-2-0--3-4-8-0-6-0-3-9 、3-5-6-2-9-4-8-9  陈先生 、曾小姐

报*名*邮*箱：baoming01&amp;lt; at &amp;gt;126.com


如不需要此类信息,请发送主题“移除”或“delete”到：tuidin01&amp;lt; at &amp;gt;163.com 　谢谢!
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
htt&lt;/pre&gt;</description>
    <dc:creator>高级管理人员</dc:creator>
    <dc:date>2010-08-06T21:12:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11693">
    <title>Linux pNFS status meeting 08/05</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11693</link>
    <description>&lt;pre&gt;Meeting on Thursday 08/05/10 at 9:30 AM pacific time (12:30 PM UMICH time)

Marc. 
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

&lt;/pre&gt;</description>
    <dc:creator>Marc Eshel</dc:creator>
    <dc:date>2010-08-05T03:53:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11687">
    <title>[RFC] Should client get lock success after NFSv4 server restart?</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11687</link>
    <description>&lt;pre&gt;Hi,

When using the NFSv4's nfslock at the latest kernel at RHEL, 
I meet a problem about the stateid, as follows.

 Step 1: Client open file, and get a LOCK.
 Step 2: Server restart the nfs service("service nfs restart").
 Step 3: Client try to get a LOCK again.

But, at step3, client get reply with error(NFS4ERR_STALE_STATEID (10023)) at NFS layer,
and fcntl return EIO.

The problem appears after Trond's patch a2c0b9e291208f65221a0ad8a0c80a377707d480,
so, there are some question about this problem.

1. IMO, in theory, Client at step3 should get lock success after server restart, right?

2. For this instance, when client get error NFS4ERR_STALE_STATEID, it should try to
   * renew * the stateid for the lock_owner is an old one at nfs4_handle_exception, 
   rather than return immediately, is that right?

3. As I known, when the lock_owner is a new one, client will try once when it's lock request 
   get error NFS4ERR_STALE_STATEID.
   IMO, the problem as above is a bug, and should be fixed, but I'm not sure!&lt;/pre&gt;</description>
    <dc:creator>Mi Jinlong</dc:creator>
    <dc:date>2010-08-03T09:41:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11685">
    <title>Linux NFSv4 Client kernel panic</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11685</link>
    <description>&lt;pre&gt;Hi,

My NFS Client is CentOS5.3 (2.6.18) and server is SUSE11. When running
LTP (ltp-full-20080930), the client crashed. the stack is below.

Kernel BUG at fs/nfs/nfs4xdr.c:872
invalid opcode: 0000 [1] SMP
last sysfs file: /block/sdb/size
CPU 0
Modules linked in: ipv6 xfrm_nalgo crypto_api autofs4 hidp l2cap
bluetooth blockvt(PU) nfs(U) lockd(U) fscache nfs_acl sunrpc ib_iser
rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi
scsi_transport_iscsi dm_mirror dm_multipath scsi_dh video hwmon
backlight sbs i2c_ec button battery asus_acpi acpi_memhotplug ac lp
floppy sg pcspkr i2c_piix4 i2c_core pcnet32 mii parport_pc parport
shpchp serio_raw dm_raid45 dm_message dm_region_hash dm_log dm_mod
dm_mem_cache ata_piix libata mptspi mptscsih mptbase
scsi_transport_spi sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Pid: 18655, comm: mknod01 Tainted: P      2.6.18-128.el5 #1
RIP: 0010:[&amp;lt;ffffffff8844841d&amp;gt;]  [&amp;lt;ffffffff8844841d&amp;gt;]
:nfs:encode_share_access+0x6d/0x82
RSP: 0018:ffff81000d4cdb18  EFLAGS: 00&lt;/pre&gt;</description>
    <dc:creator>Sid Moore</dc:creator>
    <dc:date>2010-07-30T09:13:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11666">
    <title>股权^激励法</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11666</link>
    <description>&lt;pre&gt;_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4&lt;/pre&gt;</description>
    <dc:creator>人事经理</dc:creator>
    <dc:date>2010-07-27T17:49:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11660">
    <title>Accessing mounted NFS filesystem hang when crossmnt specified on server</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11660</link>
    <description>&lt;pre&gt;I have Ubuntu server on kernel 2.6.28.

My exports:
/mnt*(sec=none,ro,fsid=0,crossmnt,insecure,no_subtree_check,sync,no_root_squash)
/home/ide*(ro,fsid=1,insecure,no_subtree_check,sync,anonuid=65534,anongid=65534)

When I mount this file system from other host with
mount -t nfs4 -o sec=none,proto=tcp,intr 10.80.1.112:/ /mnt/KVM_quad
it is mounted successfully.

But after "ls /mnt/KVM_quad", command stuck completely.

If I remove crossmnt from exports everything work OK. -t nfs, -t nfs4
- all the same. security=sys, security=none - all the same....

in /mnt dir (on nfs server) I have 10 file systems (LVM) mounted in
subdirs of /mnt. All of them are accessible.

dmesg on both systems are clear.




&lt;/pre&gt;</description>
    <dc:creator>Марк Коренберг</dc:creator>
    <dc:date>2010-07-22T13:32:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11653">
    <title>why do attempts to access a nfs v3 filesystem (ro,soft) block theprocess for minutes at a time? (when the server is down)</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11653</link>
    <description>&lt;pre&gt;
Hi all,

I have a web server which serves some content from an nfs filesystem 
mounted like so;
nfsserver1:/somemount /var/www/html/somefiles  nfs     rw,soft 
             0 0

# mount | grep nfs
nfsserver1:/somemount on /var/www/html/somefiles type nfs 
(ro,soft,addr=xx.xx.xx.xx)

According to the documentation, an NFS operation on a soft mount should 
wait for a "major timeout" and then report "server not responding" to 
syslog and return an error. where a major timeout is after default 
retrans=3 retransmissions.

I understand the process to be like this;
call ---&amp;gt;0.7 secs ---&amp;gt;retransmission---&amp;gt;1.4 
secs---&amp;gt;retransmission---&amp;gt;2.8 secs---&amp;gt;server not responding(major timeout)

However it is pretty clear that this is retrying indefinitely, as the 
log files show loads of;
Jul 16 07:56:09 server1 kernel: nfs: server server2 not responding, 
timed out
Jul 16 07:57:09 server1 last message repeated 4 times
Jul 16 07:57:09 server1 last message repeated 6 times

and eventually this kills the apache server as all &lt;/pre&gt;</description>
    <dc:creator>Tom H</dc:creator>
    <dc:date>2010-07-16T15:01:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11635">
    <title>reliability or performance benefit to changing mounts from version3 to nfsv4?</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11635</link>
    <description>&lt;pre&gt;
Hi all,

I have a nfs client/server with an assortment of mounting options and 
versions in use. I'd like to move to a standard config.

Is there a reliability benefit from mounting using nfsv4?

Thanks
T
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

&lt;/pre&gt;</description>
    <dc:creator>Tom H</dc:creator>
    <dc:date>2010-07-15T15:49:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11634">
    <title>Virus WARNING!</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11634</link>
    <description>&lt;pre&gt;Hi,

MAILER-DAEMON&amp;lt; at &amp;gt;mail.yictg.com have sent you a mail containing the virus "Worm.Mydoom.M
Worm.Mydoom.M".
The mail were deleted.
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

&lt;/pre&gt;</description>
    <dc:creator>nfsv4&lt; at &gt;linux-nfs.org</dc:creator>
    <dc:date>2010-07-15T10:45:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11631">
    <title>Linux pNFS status meeting 07/15</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11631</link>
    <description>&lt;pre&gt;Meeting on Thursday 07/15/10 at 9:30 AM pacific time (12:30 PM UMICH time)

Marc. 
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

&lt;/pre&gt;</description>
    <dc:creator>Marc Eshel</dc:creator>
    <dc:date>2010-07-14T21:20:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11627">
    <title>yyy.yy.yy.yy kernel: nfs: server XXXXX not responding, timed out</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11627</link>
    <description>&lt;pre&gt;(apologies for the cross post, but apparently I didn't get approved to
the list)


Hi all,

On some of my clients I am seeing IO errors, examining the logs reveals
quite a few entries like this;
Jul 12 02:03:46 yyy.yy.yy.yy kernel: nfs: server XXXXX not responding,
timed out

The client has mount options with nfsv3, soft, intr and all other
options default.

I am keen to understand what "not responding, timed out" means... does
that mean the server didn't respond until a "major timeout" and if so,
is this correct;

call ---&amp;gt;0.7 second ---&amp;gt;retransmission-----&amp;gt;1.4 seconds
----&amp;gt;retransmission---&amp;gt;2.8 seconds----&amp;gt;server not responding(major timeout)

if so the documentation (http://linux.die.net/man/5/nfs) says that
either the file operation is aborted OR a "server not responding"
message is printed on the console.

So its not clear whether the file operation was actually aborted. Also
does the mount automatically recover after the alert and the aborted
file operation or is the filesystem "hung" and need to be re&lt;/pre&gt;</description>
    <dc:creator>Tom H</dc:creator>
    <dc:date>2010-07-14T00:31:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11621">
    <title>Virus WARNING!</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11621</link>
    <description>&lt;pre&gt;Hi,

labaguetteriemarseille&amp;lt; at &amp;gt;wanadoo.fr have sent you a mail containing the virus "Suspect.DoubleExtension-zippwd-9
Suspect.DoubleExtension-zippwd-9".
The mail were deleted.
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

&lt;/pre&gt;</description>
    <dc:creator>nfsv4&lt; at &gt;linux-nfs.org</dc:creator>
    <dc:date>2010-07-08T07:48:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11620">
    <title>Linux pNFS status meeting 07/08</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11620</link>
    <description>&lt;pre&gt;Meeting on Thursday 07/08/10 at 9:30 AM pacific time (12:30 PM UMICH time)

Marc. 
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

&lt;/pre&gt;</description>
    <dc:creator>Marc Eshel</dc:creator>
    <dc:date>2010-07-08T02:17:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11595">
    <title>Question about implementing nfsv4 acl</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11595</link>
    <description>&lt;pre&gt;_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4&lt;/pre&gt;</description>
    <dc:creator>landry Boupana</dc:creator>
    <dc:date>2010-06-25T08:49:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11592">
    <title>Linux pNFS status meeting 06/24</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11592</link>
    <description>&lt;pre&gt;Meeting on Thursday 06/24/10 at 9:30 AM pacific time (12:30 PM UMICH time)

Marc. 
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs&amp;lt; at &amp;gt;vger.kernel.org instead.
(To subscribe to linux-nfs&amp;lt; at &amp;gt;vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org.)

NFSv4 mailing list
NFSv4&amp;lt; at &amp;gt;linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

&lt;/pre&gt;</description>
    <dc:creator>Marc Eshel</dc:creator>
    <dc:date>2010-06-24T05:20:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11585">
    <title>UID Mapping Problem</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11585</link>
    <description>&lt;pre&gt;Hello all,

I've set up a NFSv4 server using kerberos auth, and it is working
fine. However at the client machine the owner uid of the files is
always the same (and a weird number such as 4294967294). I did the
following to my idmapd.conf to get around this:

[General]
Verbosity = 3
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = USERS
[Mapping]
Nobody-User = diego
Nobody-Group = diego

This way I see every file as owned by me, and I can read and write
files just as expected. On the server side the file owner is correct
and the server denies any attempt to write on files not actually owned
by me. To illustrate this:

On the server:
root&amp;lt; at &amp;gt;filesystem:/export/pub# ls -l
total 0
-rw-r--r-- 1 diego.lima construtores 0 Jun 23 16:03 a
-rw-r--r-- 1 root       root         0 Jun 23 16:43 file

The file "a" was created by me. On the client side:

diego&amp;lt; at &amp;gt;gilead:/export/pub$ ls -l
total 0
-rw-r--r-- 1 diego diego 0 2010-06-23 16:03 a
-rw-r--r-- 1 diego diego 0 2010-06-23 16:43 file
diego&amp;lt; at &amp;gt;gilead:/export/pub$ touch file&lt;/pre&gt;</description>
    <dc:creator>Diego Lima</dc:creator>
    <dc:date>2010-06-23T19:47:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.nfsv4/11583">
    <title>remote I/O error nfs4err_resource</title>
    <link>http://comments.gmane.org/gmane.linux.nfsv4/11583</link>
    <description>&lt;pre&gt;Hello,

The last couple of days we are having an issue with our netapp filer. 
Sometimes when you access the nfs share and write/read a file , we get 
an error we never have seen before.

[root&amp;lt; at &amp;gt;nasmgt rsmits]# touch ffff
touch: cannot touch `ffff': Remote I/O error
[root&amp;lt; at &amp;gt;nasmgt rsmits]# touch ffff
touch: cannot touch `ffff': Remote I/O error
[root&amp;lt; at &amp;gt;nasmgt rsmits]# touch ffff
touch: cannot touch `ffff': Remote I/O error
[root&amp;lt; at &amp;gt;nasmgt rsmits]# touch ffff
touch: cannot touch `ffff': Remote I/O error

But 5 minutes later :

touch ffff
[root&amp;lt; at &amp;gt;nasmgt rsmits]# ll ffff
-rw-r--r-- 1 root nobody 0 2010-06-22 13:26 ffff

The file is created. We are having this a couple of times a day. I did a 
tcpdump and a pktt trace on both sides.

I see a "nfs4err_resource (10018)"

An strace on the touch command gives me this :

open("aap3", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = -1 EREMOTEIO 
(Remote I/O error)
utimensat(AT_FDCWD, "aap3", NULL, 0)    = -1 ENOENT (No such file or 
directory)

I could post the entire strace if i&lt;/pre&gt;</description>
    <dc:creator>Richard Smits</dc:creator>
    <dc:date>2010-06-23T17:57:44</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.nfsv4">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.nfsv4</link>
  </textinput>
</rdf:RDF>

