gmane.linux.nfsv4

krb5 authentication error with nfs client 1.2.x

Richard Smits — 2010-08-31T14:49:19

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< at >DOMAIN.NET'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: Success getting keytab entry 
for 'nfs/server.domain.net< at >DOMAIN.NET'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: Successfully obtained machine 
credentials for principal 'nfs/server.domain.net< at >DOMAIN.NET' stored in 
ccache 'FILE:/tmp/krb5cc_machine_DOMAIN.NET'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: INFO: Credentials in CC 
'FILE:/tmp/krb5cc_machine_DOMAIN.NET'
  are good until 1283300229
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: using 
FILE:/tmp/krb5cc_machine_DOMAIN.NET as credentials cache for machine creds
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: using environment variable to 
select krb5 ccache FILE:/tmp/krb
5cc_machine_DOMAIN.NET
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: creating context using fsuid 
0 (save_uid 0)
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: creating tcp client for 
server srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: DEBUG: port already set to 2049
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: creating context with server 
nfs< at >srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: WARNING: Failed to create 
krb5 context for user with uid 0 for
  server srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: WARNING: Failed to create 
machine krb5 context with credential
s cache FILE:/tmp/krb5cc_machine_DOMAIN.NET for server srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: WARNING: Machine cache is 
prematurely expired or corrupted try
ing to recreate cache for server srvxxx.domain.net
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< at >DOMAIN.NET'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: Success getting keytab entry 
for 'nfs/server.domain.net< at >DOMAIN.NET'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: Successfully obtained machine 
credentials for principal 'nfs/server.domain.net< at >DOMAIN.NET' stored in 
ccache 'FILE:/tmp/krb5cc_machine_DOMAIN.NET'
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: INFO: Credentials in CC 
'FILE:/tmp/krb5cc_machine_DOMAIN.NET'
  are good until 1283300229
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: using 
FILE:/tmp/krb5cc_machine_DOMAIN.NET as credentials cache for machine creds
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: using environment variable to 
select krb5 ccache FILE:/tmp/krb
5cc_machine_DOMAIN.NET
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: creating context using fsuid 
0 (save_uid 0)
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: creating tcp client for 
server srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: DEBUG: port already set to 2049
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: creating context with server 
nfs< at >srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: WARNING: Failed to create 
krb5 context for user with uid 0 for
  server srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: WARNING: Failed to create 
machine krb5 context with credential
s cache FILE:/tmp/krb5cc_machine_DOMAIN.NET for server srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: WARNING: Failed to create 
machine krb5 context with any creden
tials cache for server srvxxx.domain.net
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: doing error downcall
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: Failed to write error downcall!
Aug 31 16:17:09 vmlinux12 rpc.gssd[14072]: destroying client clnt18

Anyone an idea ?

Greetings .. Richard
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

[RFC][PATCH] nfs4: set exception->state before callingnfs4_handle_exception() for locks

Mi Jinlong — 2010-08-24T09:36:29

At the latest kernel, it is calling nfs4_handle_exception() without 
setting exception->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->state before calling nfs4_handle_exception()
and also modifies nfs4_recovery_handle_error().

Signed-off-by: Mi Jinlong <mijinlong< at >cn.fujitsu.com>

---
 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
< at >< at > -4233,7 +4233,9 < at >< at > 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 *request)
 {
 struct nfs_server *server = NFS_SERVER(state->inode);
-struct nfs4_exception exception = { };
+struct nfs4_exception exception = {
+.state = state,
+};
 int err;
 
 do {
< at >< at > -4251,7 +4253,9 < at >< at > static int nfs4_lock_reclaim(struct nfs4_state *state, struct file_lock *request
 static int nfs4_lock_expired(struct nfs4_state *state, struct file_lock *request)
 {
 struct nfs_server *server = NFS_SERVER(state->inode);
-struct nfs4_exception exception = { };
+struct nfs4_exception exception = {
+.state = state,
+};
 int err;
 
 err = nfs4_set_lock_state(state, request);
< at >< at > -4316,7 +4320,9 < at >< at > out:
 
 static int nfs4_proc_setlk(struct nfs4_state *state, int cmd, struct file_lock *request)
 {
-struct nfs4_exception exception = { };
+struct nfs4_exception exception = {
+.state = state,
+};
 int err;
 
 do {
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 3e2f19b..8bda922 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
< at >< at > -1184,10 +1184,10 < at >< at > static int nfs4_recovery_handle_error(struct nfs_client *clp, int error)
 case -NFS4ERR_NO_GRACE:
 nfs4_state_end_reclaim_reboot(clp);
 return 0;
-case -NFS4ERR_STALE_CLIENTID:
 case -NFS4ERR_LEASE_MOVED:
-set_bit(NFS4CLNT_LEASE_EXPIRED, &clp->cl_state);
 nfs4_state_end_reclaim_reboot(clp);
+case -NFS4ERR_STALE_CLIENTID:
+set_bit(NFS4CLNT_LEASE_EXPIRED, &clp->cl_state);
 nfs4_state_start_reclaim_reboot(clp);
 break;
 case -NFS4ERR_EXPIRED:

Can create and delete but not overwrite

Steve Gaarder — 2010-08-13T20:47:42

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 >foo

works, but a subsequent

echo foo >foo

says "Input/Output Error".

Any ideas?

就知道中秋节你会被铺天盖地的短信包围，英明的乙辉缇腿米８？绻，闪过卖茶叶蛋的老太太，钻进你的耳朵：祝中秋炖郑

carrierebouvy — 2010-08-10T21:46:15

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

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

办公技能

高级管理人员 — 2010-08-06T21:12:33

您   好：


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

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

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

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


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

报*名*邮*箱：baoming01< at >126.com


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

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Linux pNFS status meeting 08/05

Marc Eshel — 2010-08-05T03:53:29

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< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

[RFC] Should client get lock success after NFSv4 server restart?

Mi Jinlong — 2010-08-03T09:41:53

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!

   Waiting your idea ...

thanks,
Mi Jinlong

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

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Linux NFSv4 Client kernel panic

Sid Moore — 2010-07-30T09:13:28

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:[<ffffffff8844841d>]  [<ffffffff8844841d>]
:nfs:encode_share_access+0x6d/0x82
RSP: 0018:ffff81000d4cdb18  EFLAGS: 00010297
RAX: 00000000ffffffff RBX: ffff810007c770b8 RCX: ffff810007c770b8
RDX: 0000000000000008 RSI: 0000000000000008 RDI: ffff81000d4cdb68
RBP: 0000000000000080 R08: ffff810007c770ac R09: 0000000000000009
R10: ffff81000601e980 R11: ffffffff8844bc69 R12: ffff81000d4cdb68
R13: ffff81000216d158 R14: ffff81000d4cde18 R15: ffff810002912000
FS:  00002b7f2d2c3210(0000) GS:ffffffff803ac000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000003ec6a41900 CR3: 0000000007c10000 CR4: 00000000000006e0
Process mknod01 (pid: 18655, threadinfo ffff81000d4cc000, task ffff810004308040)
Stack:  ffff810004308040 ffff810007c770b0 ffff81000834f408 ffffffff8844b919
 ffff8100080b7df8 ffff81000216d158 ffff81000834f408 ffffffff8844bc69
 ffff81000216d158 ffffffff8844bcd6 ffff810007c770c0 ffff81000216d160
Call Trace:
 [<ffffffff8844b919>] :nfs:encode_open+0x66/0x33e
 [<ffffffff8844bc69>] :nfs:nfs4_xdr_enc_open+0x0/0xac
 [<ffffffff8844bcd6>] :nfs:nfs4_xdr_enc_open+0x6d/0xac
 [<ffffffff8844bc69>] :nfs:nfs4_xdr_enc_open+0x0/0xac
 [<ffffffff883c63f0>] :sunrpc:call_transmit+0x1bc/0x222
 [<ffffffff883cb923>] :sunrpc:__rpc_execute+0x92/0x24e
 [<ffffffff883cbb36>] :sunrpc:rpc_run_task+0x37/0x3f
 [<ffffffff884430e0>] :nfs:_nfs4_proc_open+0x50/0x1aa
 [<ffffffff88443ff2>] :nfs:nfs4_do_open+0xc2/0x1dd
 [<ffffffff884459a4>] :nfs:nfs4_proc_create+0x7f/0x1b2
 [<ffffffff883cc91a>] :sunrpc:rpcauth_lookup_credcache+0x12e/0x24c
 [<ffffffff8842d3c4>] :nfs:nfs_access_get_cached+0xab/0xfa
 [<ffffffff8842e440>] :nfs:nfs_create+0x87/0xed
 [<ffffffff8002221b>] d_alloc+0x174/0x1a9
 [<ffffffff8003a031>] vfs_create+0xe6/0x158
 [<ffffffff800e3120>] sys_mknodat+0x107/0x188
 [<ffffffff8005d229>] tracesys+0x71/0xe0
 [<ffffffff8005d28d>] tracesys+0xd5/0xe0


Code: 0f 0b 68 14 5e 45 88 c2 68 03 c7 03 00 00 00 00 41 5a 5b 5d
RIP  [<ffffffff8844841d>] :nfs:encode_share_access+0x6d/0x82
 RSP <ffff81000d4cdb18>
 <0>Kernel panic - not syncing: Fatal exception

I think open_flags was set to be zero when calling
encode_share_access(), but I don't know what happened and triggered
this crash.
is anyone willing to help me ?

Best,
sid
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

股权^激励法

人事经理 — 2010-07-27T17:49:49

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

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Accessing mounted NFS filesystem hang when crossmnt specified on server

Марк Коренберг — 2010-07-22T13:32:29

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.

why do attempts to access a nfs v3 filesystem (ro,soft) block theprocess for minutes at a time? (when the server is down)

Tom H — 2010-07-16T15:01:32

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 --->0.7 secs --->retransmission--->1.4 
secs--->retransmission--->2.8 secs--->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 the available 
processes are blocked during "retrying indefinitely", until the apache 
server is restarted. (restarting the nfs server at this point does not 
seem to recover the apache child processes)

So what should my strategy be to stop the failed mount killing apache. I 
care more about the apache staying up, as I don't have that much control 
over the nfs server..

(also I noticed that it seems to timeout quicker with the mount options 
set like (soft, timeo=7, retrans=3) which is unexpected, because they 
are supposed to be the default)

Regards and thanks in advance,
T



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

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

reliability or performance benefit to changing mounts from version3 to nfsv4?

Tom H — 2010-07-15T15:49:08

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< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Virus WARNING!

2010-07-15T10:45:00

Hi,

MAILER-DAEMON< at >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< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Linux pNFS status meeting 07/15

Marc Eshel — 2010-07-14T21:20:05

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< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

yyy.yy.yy.yy kernel: nfs: server XXXXX not responding, timed out

Tom H — 2010-07-14T00:31:22

(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 --->0.7 second --->retransmission----->1.4 seconds
---->retransmission--->2.8 seconds---->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 remounted?

If the mount was default hard mount, then it seems that retransmissions
would keep happening until the maximum timeout. So in this case would it
go like this;

call --->0.7 secs --->retrans-->1.4 secs --->retrans--->2.8
seconds-->retrans---> ... keep doubling until 60 secs --->retrans--->60
seconds-->retrans--->60 seconds--->etc etc


Thanks

T


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

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Virus WARNING!

2010-07-08T07:48:27

Hi,

labaguetteriemarseille< at >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< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Linux pNFS status meeting 07/08

Marc Eshel — 2010-07-08T02:17:01

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< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Question about implementing nfsv4 acl

landry Boupana — 2010-06-25T08:49:13

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

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Linux pNFS status meeting 06/24

Marc Eshel — 2010-06-24T05:20:26

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< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

UID Mapping Problem

Diego Lima — 2010-06-23T19:47:46

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< at >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< at >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< at >gilead:/export/pub$ touch file2
diego< at >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
-rw-r--r-- 1 diego diego 0 2010-06-23 16:47 file2
diego< at >gilead:/export/pub$ rm file2
diego< at >gilead:/export/pub$ rm file
rm: remove write-protected regular empty file `file'? y
rm: cannot remove `file': Operation not permitted

Is there any way to map the files I actually own to my user instead of
mapping everything?

Thanks!

remote I/O error nfs4err_resource

Richard Smits — 2010-06-23T17:57:44

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< at >nasmgt rsmits]# touch ffff
touch: cannot touch `ffff': Remote I/O error
[root< at >nasmgt rsmits]# touch ffff
touch: cannot touch `ffff': Remote I/O error
[root< at >nasmgt rsmits]# touch ffff
touch: cannot touch `ffff': Remote I/O error
[root< at >nasmgt rsmits]# touch ffff
touch: cannot touch `ffff': Remote I/O error

But 5 minutes later :

touch ffff
[root< at >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 it would help.

Anyone has got an idea what this could be ?

Greetings .. Richard
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs< at >vger.kernel.org instead.
(To subscribe to linux-nfs< at >vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo< at >vger.kernel.org.)

NFSv4 mailing list
NFSv4< at >linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4