* Different sequence of "exportfs" produce different effects on nfs client mounts
@ 2013-10-14 2:16 Wangminlan
2013-10-14 17:45 ` J. Bruce Fields
0 siblings, 1 reply; 13+ messages in thread
From: Wangminlan @ 2013-10-14 2:16 UTC (permalink / raw)
To: linux-nfs
44CA44CASGksDQrjgIDjgIAgICAgICAgICBJ4oCZdmUgZ290IGEgcHJvYmxlbSBvbiB0aGUgbmZz
IGV4cG9ydGZzIGNvbW1hbmQuIEnigJltIG5vdCBzdXJlIGlmIHRoaXMgaXMgdGhlIHJpZ2h0IHBs
YWNlIHRvIGFzayB0aGlzLCBpZiBub3QsIGNhbiB5b3UgcGxlYXNlIHRlbGwgbWUgd2hlcmU/DQrj
gIDjgIANCuOAgOOAgCAgICAgICAgIEhlcmXigJlzIHdoYXQgSSBuZWVkOg0K44CA44CAMS4gSSBo
YXZlIGEgZm9sZGVyIG5hbWVkIC9tbnQvZnMxIHRvIGJlIGV4cG9ydGVkLg0K44CA44CAMi4gQWxs
IHRoZSBob3N0IGluIHN1Ym5ldHdvcmsgMTkyLjE2OC4wLjAvMTYgc2hvdWxkIGJlIGFibGUgYWNj
ZXNzIHRoaXMgZm9sZGVyLCBidXQgdGhlaXIgcm9vdCBzaG91bGQgYmUgc3F1YXNoZWQuDQrjgIDj
gIAzLiBTb21lIHNwZWNpZmllZCBob3N0IGluIHRoZSBzYW1lIHN1Ym5ldHdvcmsgY2FuIGdhaW4g
dGhlIHJvb3QgcGVybWlzc2lvbiBvbiB0aGUgZm9sZGVyLCBmb3IgZXhhbXBsZTogMTkyLjE2OC4w
LjIxLCAxOTIuMTY4LjAuMjIuDQrjgIDjgIANCuOAgOOAgEnigJl2ZSBnb3QgYSBTTEVTMTFTUDEg
Ym94IGFzIHRoZSBuZnMgc2VydmVyLCB0aGUgbmZzIGNsaWVudHMgYXJlIFNMRVMxMVNQMSwgdG9v
LCBhbmQgdGhlIHByb3RvY29sIHVzZWQgYmV0d2VlbiBjbGllbnRzIGFuZCBzZXJ2ZXIgYXJlIE5G
U3YzLg0K44CA44CASGVyZSBhcmUgdGhlIGNvbW1hbmRzIEkgdXNlZCB0byBkbyB0aGUgZXhwb3J0
Og0K44CA44CAI2V4cG9ydGZzIOKAk28gcncscm9vdF9zcXVhc2ggMTkyLjE2OC4wLjAvMTY6L21u
dC9mczEgDQrjgIDjgIAjZXhwb3J0ZnMg4oCTbyBydyxub19yb290X3NxdWFzaCAxOTIuMTY4LjAu
MjE6L21udC9mczEgDQrjgIDjgIAjZXhwb3J0ZnMg4oCTbyBydyxub19yb290X3NxdWFzaCAxOTIu
MTY4LjAuMjI6L21udC9mczENCuOAgOOAgEFmdGVyIHRoaXMsIGV2ZXJ5dGhpbmcgd29ya3MgYXMg
ZXhwZWN0ZWQuDQrjgIDjgIANCuOAgOOAgEJ1dCwgYWZ0ZXIgdGhlIGZvbGxvd2luZyBvcGVyYXRp
b25zOg0K44CA44CAI2V4cG9ydGZzIOKAk3UgMTkyLjE2OC4wLjAvMTY6L21udC9mczEgICAgICAg
ICAgICAgIC8qIERlbGV0ZSB0aGlzIGV4cG9ydCAqLw0K44CA44CAIyBleHBvcnRmcyDigJNvIHJ3
LHJvb3Rfc3F1YXNoIDE5Mi4xNjguMC4wLzE2Oi9tbnQvZnMxICAgICAgICAgIC8qIEFuZCBhZGQg
aXQgYWdhaW4gKi8NCuOAgOOAgEhvc3RzIG9uIDE5Mi4xNjguMC4yMSBhbmQgMTkyLjE2OC4wLjIy
IGRvZXNu4oCZdCBnZXQgcm9vdCBwZXJtaXNzaW9uIGFueSBtb3JlLiB3aGVuIEkgdHJpZWQgdG8g
d3JpdGUgYSBmaWxlLCBpdCBjb21wbGFpbnMgYWJvdXQg4oCcUGVybWlzc2lvbiBkZW5pZWTigJ0u
DQrjgIDjgIANCuOAgOOAgFNvLCBkb2VzIHRoZSBvcmRlciBvZiBleHBvcnRmcyBjb21tYW5kIGhh
cyBzb21ldGhpbmcgdG8gZG8gdGhlIGZpbmFsIHJlc3VsdD8gT3IgYW0gSSBkb2luZyBzb21ldGhp
bmcgd3Jvbmc/DQrjgIDjgIANCuOAgOOAgEIuUg0K44CA44CATWlubGFuIFdhbmcNCg==
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-14 2:16 Different sequence of "exportfs" produce different effects on nfs client mounts Wangminlan
@ 2013-10-14 17:45 ` J. Bruce Fields
2013-10-15 6:39 ` Wangminlan
0 siblings, 1 reply; 13+ messages in thread
From: J. Bruce Fields @ 2013-10-14 17:45 UTC (permalink / raw)
To: Wangminlan; +Cc: linux-nfs
On Mon, Oct 14, 2013 at 02:16:58AM +0000, Wangminlan wrote:
> Hi,
> I’ve got a problem on the nfs exportfs command. I’m not sure if this is the right place to ask this, if not, can you please tell me where?
>
> Here’s what I need:
> 1. I have a folder named /mnt/fs1 to be exported.
> 2. All the host in subnetwork 192.168.0.0/16 should be able access this folder, but their root should be squashed.
> 3. Some specified host in the same subnetwork can gain the root permission on the folder, for example: 192.168.0.21, 192.168.0.22.
>
> I’ve got a SLES11SP1 box as the nfs server, the nfs clients are SLES11SP1, too, and the protocol used between clients and server are NFSv3.
> Here are the commands I used to do the export:
> #exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1
> #exportfs –o rw,no_root_squash 192.168.0.21:/mnt/fs1
> #exportfs –o rw,no_root_squash 192.168.0.22:/mnt/fs1
> After this, everything works as expected.
>
> But, after the following operations:
> #exportfs –u 192.168.0.0/16:/mnt/fs1 /* Delete this export */
> # exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1 /* And add it again */
> Hosts on 192.168.0.21 and 192.168.0.22 doesn’t get root permission any more. when I tried to write a file, it complains about “Permission denied”.
>
> So, does the order of exportfs command has something to do the final result? Or am I doing something wrong?
That sounds like a bug. The contents of
/proc/net/rpc/auth.unix.ip/content and /proc/net/rpc/nfsd.export/content
after getting the above "permission denied" might be interesting.
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-14 17:45 ` J. Bruce Fields
@ 2013-10-15 6:39 ` Wangminlan
2013-10-15 15:49 ` J. Bruce Fields
0 siblings, 1 reply; 13+ messages in thread
From: Wangminlan @ 2013-10-15 6:39 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-nfs
T24gTW9uLCBPY3QgMTQsIDIwMTMgYXQgMTY6NDYgKzAwMDAsIEJydWNlIEZpZWxkcyB3cm90ZToN
Cj4gT24gTW9uLCBPY3QgMTQsIDIwMTMgYXQgMDI6MTY6NThBTSArMDAwMCwgV2FuZ21pbmxhbiB3
cm90ZToNCj4gPiDjgIDjgIBIaSwNCj4gPiDjgIDjgIAgICAgICAgICBJ4oCZdmUgZ290IGEgcHJv
YmxlbSBvbiB0aGUgbmZzIGV4cG9ydGZzIGNvbW1hbmQuIEnigJltIG5vdA0KPiBzdXJlIGlmIHRo
aXMgaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIGFzayB0aGlzLCBpZiBub3QsIGNhbiB5b3UgcGxlYXNl
IHRlbGwgbWUgd2hlcmU/DQo+ID4NCj4gPiDjgIDjgIAgICAgICAgICBIZXJl4oCZcyB3aGF0IEkg
bmVlZDoNCj4gPiDjgIDjgIAxLiBJIGhhdmUgYSBmb2xkZXIgbmFtZWQgL21udC9mczEgdG8gYmUg
ZXhwb3J0ZWQuDQo+ID4g44CA44CAMi4gQWxsIHRoZSBob3N0IGluIHN1Ym5ldHdvcmsgMTkyLjE2
OC4wLjAvMTYgc2hvdWxkIGJlIGFibGUgYWNjZXNzIHRoaXMNCj4gZm9sZGVyLCBidXQgdGhlaXIg
cm9vdCBzaG91bGQgYmUgc3F1YXNoZWQuDQo+ID4g44CA44CAMy4gU29tZSBzcGVjaWZpZWQgaG9z
dCBpbiB0aGUgc2FtZSBzdWJuZXR3b3JrIGNhbiBnYWluIHRoZSByb290DQo+IHBlcm1pc3Npb24g
b24gdGhlIGZvbGRlciwgZm9yIGV4YW1wbGU6IDE5Mi4xNjguMC4yMSwgMTkyLjE2OC4wLjIyLg0K
PiA+DQo+ID4g44CA44CASeKAmXZlIGdvdCBhIFNMRVMxMVNQMSBib3ggYXMgdGhlIG5mcyBzZXJ2
ZXIsIHRoZSBuZnMgY2xpZW50cyBhcmUgU0xFUzExU1AxLA0KPiB0b28sIGFuZCB0aGUgcHJvdG9j
b2wgdXNlZCBiZXR3ZWVuIGNsaWVudHMgYW5kIHNlcnZlciBhcmUgTkZTdjMuDQo+ID4g44CA44CA
SGVyZSBhcmUgdGhlIGNvbW1hbmRzIEkgdXNlZCB0byBkbyB0aGUgZXhwb3J0Og0KPiA+IOOAgOOA
gCNleHBvcnRmcyDigJNvIHJ3LHJvb3Rfc3F1YXNoIDE5Mi4xNjguMC4wLzE2Oi9tbnQvZnMxDQo+
ID4g44CA44CAI2V4cG9ydGZzIOKAk28gcncsbm9fcm9vdF9zcXVhc2ggMTkyLjE2OC4wLjIxOi9t
bnQvZnMxDQo+ID4g44CA44CAI2V4cG9ydGZzIOKAk28gcncsbm9fcm9vdF9zcXVhc2ggMTkyLjE2
OC4wLjIyOi9tbnQvZnMxDQo+ID4g44CA44CAQWZ0ZXIgdGhpcywgZXZlcnl0aGluZyB3b3JrcyBh
cyBleHBlY3RlZC4NCkFmdGVyIHRoaXMsIHRoZSBjb250ZW50cyBvZiAvcHJvYy9uZXQvcnBjL2F1
dGgudW5peC5pcC9jb250ZW50IGFuZCAvcHJvYy9uZXQvcnBjL25mc2QuZXhwb3J0L2NvbnRlbnQg
YXJlOg0KCU5WMjAwXzAxOi9wcm9jL25ldC9ycGMgIyBjYXQgYXV0aC51bml4LmlwL2NvbnRlbnQg
DQoJI2NsYXNzIElQIGRvbWFpbg0KCW5mc2QgMTkyLjE2OC4wLjIxIDE5Mi4xNjguMC4wLzE2LDE5
Mi4xNjguMC4yMQ0KCW5mc2QgMC4wLjAuMCAtdGVzdC1jbGllbnQtDQoJIyBuZnNkIDEwMC40My4x
ODkuMSAtbm8tZG9tYWluLQ0KDQoJTlYyMDBfMDE6L3Byb2MvbmV0L3JwYyAjIGNhdCBuZnNkLmV4
cG9ydC9jb250ZW50IA0KCSNwYXRoIGRvbWFpbihmbGFncykNCgkvbW50L2ZzMQktdGVzdC1jbGll
bnQtKHJ3LG5vX3Jvb3Rfc3F1YXNoLHN5bmMsbm9fd2RlbGF5LGZzaWQ9MCxhbm9udWlkPTQyOTQ5
NjcyOTUsYW5vbmdpZD00Mjk0OTY3Mjk1KQ0KCS9tbnQvZnMxCTE5Mi4xNjguMC4wLzE2LDE5Mi4x
NjguMC4yMShydyxub19yb290X3NxdWFzaCxzeW5jLHdkZWxheSxub19zdWJ0cmVlX2NoZWNrLHV1
aWQ9MTMyNjZmMGQ6MWZiZDQwZDU6YjBiNWM0ZmU6Y2ZlMTA0ZWIpDQoJIyAvbW50L2ZzMQkxOTIu
MTY4LjAuMC8xNiwxOTIuMTY4LjAuMjEocncsbm9fcm9vdF9zcXVhc2gsc3luYyx3ZGVsYXksbm9f
c3VidHJlZV9jaGVjayx1dWlkPTEzMjY2ZjBkOjFmYmQ0MGQ1OmIwYjVjNGZlOmNmZTEwNGViKQ0K
QmVzaWRlcywgdGhlIGNvbnRlbnQgb2YgL3Zhci9saWIvbmZzL2V0YWIgaXM6DQoJTlYyMDBfMDE6
L3Byb2MvbmV0L3JwYyAjIGNhdCAvdmFyL2xpYi9uZnMvZXRhYiANCgkvbW50L2ZzMQkxOTIuMTY4
LjAuMjIocncsc3luYyx3ZGVsYXksaGlkZSxub2Nyb3NzbW50LHNlY3VyZSxub19yb290X3NxdWFz
aCxub19hbGxfc3F1YXNoLG5vX3N1YnRyZWVfY2hlY2ssc2VjdXJlX2xvY2tzLGFjbCxhbm9udWlk
PTY1NTM0LGFub25naWQ9NjU1MzQpDQoJL21udC9mczEJMTkyLjE2OC4wLjIxKHJ3LHN5bmMsd2Rl
bGF5LGhpZGUsbm9jcm9zc21udCxzZWN1cmUsbm9fcm9vdF9zcXVhc2gsbm9fYWxsX3NxdWFzaCxu
b19zdWJ0cmVlX2NoZWNrLHNlY3VyZV9sb2NrcyxhY2wsYW5vbnVpZD02NTUzNCxhbm9uZ2lkPTY1
NTM0KQ0KCS9tbnQvZnMxCTE5Mi4xNjguMC4wLzE2KHJ3LHN5bmMsd2RlbGF5LGhpZGUsbm9jcm9z
c21udCxzZWN1cmUscm9vdF9zcXVhc2gsbm9fYWxsX3NxdWFzaCxub19zdWJ0cmVlX2NoZWNrLHNl
Y3VyZV9sb2NrcyxhY2wsYW5vbnVpZD02NTUzNCxhbm9uZ2lkPTY1NTM0KQ0KPiA+DQo+ID4g44CA
44CAQnV0LCBhZnRlciB0aGUgZm9sbG93aW5nIG9wZXJhdGlvbnM6DQo+ID4g44CA44CAI2V4cG9y
dGZzIOKAk3UgMTkyLjE2OC4wLjAvMTY6L21udC9mczEgICAgICAgICAgICAgIC8qIERlbGV0ZSB0
aGlzDQo+IGV4cG9ydCAqLw0KPiA+IOOAgOOAgCMgZXhwb3J0ZnMg4oCTbyBydyxyb290X3NxdWFz
aCAxOTIuMTY4LjAuMC8xNjovbW50L2ZzMSAgICAgICAgICAvKg0KPiBBbmQgYWRkIGl0IGFnYWlu
ICovDQo+ID4g44CA44CASG9zdHMgb24gMTkyLjE2OC4wLjIxIGFuZCAxOTIuMTY4LjAuMjIgZG9l
c27igJl0IGdldCByb290IHBlcm1pc3Npb24NCj4gYW55IG1vcmUuIHdoZW4gSSB0cmllZCB0byB3
cml0ZSBhIGZpbGUsIGl0IGNvbXBsYWlucyBhYm91dCDigJxQZXJtaXNzaW9uIGRlbmllZOKAnS4N
Cj4gPg0KPiA+IOOAgOOAgFNvLCBkb2VzIHRoZSBvcmRlciBvZiBleHBvcnRmcyBjb21tYW5kIGhh
cyBzb21ldGhpbmcgdG8gZG8gdGhlIGZpbmFsDQo+IHJlc3VsdD8gT3IgYW0gSSBkb2luZyBzb21l
dGhpbmcgd3Jvbmc/DQpBZnRlciB0aGlzLCB0aGUgY29udGVudHMgb2YgL3Byb2MvbmV0L3JwYy9h
dXRoLnVuaXguaXAvY29udGVudCBhbmQgL3Byb2MvbmV0L3JwYy9uZnNkLmV4cG9ydC9jb250ZW50
IGFyZToNCglOVjIwMF8wMTovcHJvYy9uZXQvcnBjICMgY2F0IGF1dGgudW5peC5pcC9jb250ZW50
IA0KCSNjbGFzcyBJUCBkb21haW4NCgluZnNkIDE5Mi4xNjguMC4yMSAxOTIuMTY4LjAuMC8xNiwx
OTIuMTY4LjAuMjENCgluZnNkIDAuMC4wLjAgLXRlc3QtY2xpZW50LQ0KCSMgbmZzZCAxMDAuNDMu
MTg5LjEgLW5vLWRvbWFpbi0NCg0KCU5WMjAwXzAxOi9wcm9jL25ldC9ycGMgIyBjYXQgbmZzZA0K
CW5mc2QgICAgICAgICBuZnNkLmV4cG9ydC8gbmZzZC5maC8gICAgIA0KCU5WMjAwXzAxOi9wcm9j
L25ldC9ycGMgIyBjYXQgbmZzZA0KCW5mc2QgICAgICAgICBuZnNkLmV4cG9ydC8gbmZzZC5maC8g
ICAgIA0KCU5WMjAwXzAxOi9wcm9jL25ldC9ycGMgIyBjYXQgbmZzZC5leHBvcnQvY29udGVudCAN
CgkjcGF0aCBkb21haW4oZmxhZ3MpDQoJL21udC9mczEJLXRlc3QtY2xpZW50LShydyxub19yb290
X3NxdWFzaCxzeW5jLG5vX3dkZWxheSxmc2lkPTAsYW5vbnVpZD00Mjk0OTY3Mjk1LGFub25naWQ9
NDI5NDk2NzI5NSkNCgkvbW50L2ZzMQkxOTIuMTY4LjAuMC8xNiwxOTIuMTY4LjAuMjEocncscm9v
dF9zcXVhc2gsc3luYyx3ZGVsYXksbm9fc3VidHJlZV9jaGVjayx1dWlkPTEzMjY2ZjBkOjFmYmQ0
MGQ1OmIwYjVjNGZlOmNmZTEwNGViKQ0KQW5kIHRoZSBjb250ZW50IG9mIC92YXIvbGliL25mcy9l
dGFiIGlzOg0KCU5WMjAwXzAxOi9wcm9jL25ldC9ycGMgIyBjYXQgL3Zhci9saWIvbmZzL2V0YWIg
DQoJL21udC9mczEJMTkyLjE2OC4wLjAvMTYocncsc3luYyx3ZGVsYXksaGlkZSxub2Nyb3NzbW50
LHNlY3VyZSxyb290X3NxdWFzaCxub19hbGxfc3F1YXNoLG5vX3N1YnRyZWVfY2hlY2ssc2VjdXJl
X2xvY2tzLGFjbCxhbm9udWlkPTY1NTM0LGFub25naWQ9NjU1MzQpDQoJL21udC9mczEJMTkyLjE2
OC4wLjIyKHJ3LHN5bmMsd2RlbGF5LGhpZGUsbm9jcm9zc21udCxzZWN1cmUsbm9fcm9vdF9zcXVh
c2gsbm9fYWxsX3NxdWFzaCxub19zdWJ0cmVlX2NoZWNrLHNlY3VyZV9sb2NrcyxhY2wsYW5vbnVp
ZD02NTUzNCxhbm9uZ2lkPTY1NTM0KQ0KCS9tbnQvZnMxCTE5Mi4xNjguMC4yMShydyxzeW5jLHdk
ZWxheSxoaWRlLG5vY3Jvc3NtbnQsc2VjdXJlLG5vX3Jvb3Rfc3F1YXNoLG5vX2FsbF9zcXVhc2gs
bm9fc3VidHJlZV9jaGVjayxzZWN1cmVfbG9ja3MsYWNsLGFub251aWQ9NjU1MzQsYW5vbmdpZD02
NTUzNCkNCj4gDQo+IFRoYXQgc291bmRzIGxpa2UgYSBidWcuICBUaGUgY29udGVudHMgb2YNCj4g
L3Byb2MvbmV0L3JwYy9hdXRoLnVuaXguaXAvY29udGVudCBhbmQgL3Byb2MvbmV0L3JwYy9uZnNk
LmV4cG9ydC9jb250ZW50DQo+IGFmdGVyIGdldHRpbmcgdGhlIGFib3ZlICJwZXJtaXNzaW9uIGRl
bmllZCIgbWlnaHQgYmUgaW50ZXJlc3RpbmcuDQo=
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-15 6:39 ` Wangminlan
@ 2013-10-15 15:49 ` J. Bruce Fields
2013-10-16 1:22 ` Wangminlan
0 siblings, 1 reply; 13+ messages in thread
From: J. Bruce Fields @ 2013-10-15 15:49 UTC (permalink / raw)
To: Wangminlan; +Cc: linux-nfs
Looking at the mountd code....
Looks like utils/mountd/cache.c makes no special effort to prioritize
exports except in the v4root and crossmnt cases, neither an issue in
your case.
So yes it depends on ordering. From man exports:
If a client matches more than one of the specifications above,
then the first match from the above list order takes precedence
- regardless of the order they appear on the export line.
However, if a client matches more than one of the same type of
specification (e.g. two netgroups), then the first match
from the order they appear on the export line takes
precedence.
The order given is: single host, IP networks, wildcards, negroups,
anonymous.
So the single host exports should have taken precedence.
The code here does look like it corectly implements the above ordering.
What version of nfs-utils are you using?
--b.
On Tue, Oct 15, 2013 at 06:39:59AM +0000, Wangminlan wrote:
> On Mon, Oct 14, 2013 at 16:46 +0000, Bruce Fields wrote:
> > On Mon, Oct 14, 2013 at 02:16:58AM +0000, Wangminlan wrote:
> > > Hi,
> > > I’ve got a problem on the nfs exportfs command. I’m not
> > sure if this is the right place to ask this, if not, can you please tell me where?
> > >
> > > Here’s what I need:
> > > 1. I have a folder named /mnt/fs1 to be exported.
> > > 2. All the host in subnetwork 192.168.0.0/16 should be able access this
> > folder, but their root should be squashed.
> > > 3. Some specified host in the same subnetwork can gain the root
> > permission on the folder, for example: 192.168.0.21, 192.168.0.22.
> > >
> > > I’ve got a SLES11SP1 box as the nfs server, the nfs clients are SLES11SP1,
> > too, and the protocol used between clients and server are NFSv3.
> > > Here are the commands I used to do the export:
> > > #exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1
> > > #exportfs –o rw,no_root_squash 192.168.0.21:/mnt/fs1
> > > #exportfs –o rw,no_root_squash 192.168.0.22:/mnt/fs1
> > > After this, everything works as expected.
> After this, the contents of /proc/net/rpc/auth.unix.ip/content and /proc/net/rpc/nfsd.export/content are:
> NV200_01:/proc/net/rpc # cat auth.unix.ip/content
> #class IP domain
> nfsd 192.168.0.21 192.168.0.0/16,192.168.0.21
> nfsd 0.0.0.0 -test-client-
> # nfsd 100.43.189.1 -no-domain-
>
> NV200_01:/proc/net/rpc # cat nfsd.export/content
> #path domain(flags)
> /mnt/fs1 -test-client-(rw,no_root_squash,sync,no_wdelay,fsid=0,anonuid=4294967295,anongid=4294967295)
> /mnt/fs1 192.168.0.0/16,192.168.0.21(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> # /mnt/fs1 192.168.0.0/16,192.168.0.21(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> Besides, the content of /var/lib/nfs/etab is:
> NV200_01:/proc/net/rpc # cat /var/lib/nfs/etab
> /mnt/fs1 192.168.0.22(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
> /mnt/fs1 192.168.0.21(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
> /mnt/fs1 192.168.0.0/16(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
> > >
> > > But, after the following operations:
> > > #exportfs –u 192.168.0.0/16:/mnt/fs1 /* Delete this
> > export */
> > > # exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1 /*
> > And add it again */
> > > Hosts on 192.168.0.21 and 192.168.0.22 doesn’t get root permission
> > any more. when I tried to write a file, it complains about “Permission denied”.
> > >
> > > So, does the order of exportfs command has something to do the final
> > result? Or am I doing something wrong?
> After this, the contents of /proc/net/rpc/auth.unix.ip/content and /proc/net/rpc/nfsd.export/content are:
> NV200_01:/proc/net/rpc # cat auth.unix.ip/content
> #class IP domain
> nfsd 192.168.0.21 192.168.0.0/16,192.168.0.21
> nfsd 0.0.0.0 -test-client-
> # nfsd 100.43.189.1 -no-domain-
>
> NV200_01:/proc/net/rpc # cat nfsd
> nfsd nfsd.export/ nfsd.fh/
> NV200_01:/proc/net/rpc # cat nfsd
> nfsd nfsd.export/ nfsd.fh/
> NV200_01:/proc/net/rpc # cat nfsd.export/content
> #path domain(flags)
> /mnt/fs1 -test-client-(rw,no_root_squash,sync,no_wdelay,fsid=0,anonuid=4294967295,anongid=4294967295)
> /mnt/fs1 192.168.0.0/16,192.168.0.21(rw,root_squash,sync,wdelay,no_subtree_check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> And the content of /var/lib/nfs/etab is:
> NV200_01:/proc/net/rpc # cat /var/lib/nfs/etab
> /mnt/fs1 192.168.0.0/16(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
> /mnt/fs1 192.168.0.22(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
> /mnt/fs1 192.168.0.21(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
> >
> > That sounds like a bug. The contents of
> > /proc/net/rpc/auth.unix.ip/content and /proc/net/rpc/nfsd.export/content
> > after getting the above "permission denied" might be interesting.
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-15 15:49 ` J. Bruce Fields
@ 2013-10-16 1:22 ` Wangminlan
2013-10-17 7:16 ` Wangminlan
0 siblings, 1 reply; 13+ messages in thread
From: Wangminlan @ 2013-10-16 1:22 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-nfs
SGksIEJydWNlLA0KCVRoZSBuZnMtdXRpbHMgb24gbXkgYm94IGlzIG5mcy11dGlscy0xLjIuMS0y
LjYuNiwgd2hpY2ggaXMgU3VzZSBkaXN0cmlidXRlZC4NCglJIHRyaWVkIHRoZSBzYW1lIGV4cGVy
aW1lbnQgb24gZmVkb3JhMTgsIHdoaWNoIHVzZSBuZnMtdXRpbHMtMS4yLjYsIGFuZCBnb3QgdGhl
IHNhbWUgcmVzdWx0Lg0KCUkgZ28gdGhyb3VnaCB0aGUgY29kZSBvZiBzdXBwb3J0L2V4cG9ydC9j
bGllbnQuYywgZm91bmQgdGhhdCBpbiBjbGllbnRfZ2V0X3R5cGUoKSwgd2hlbiB0aGUgY2xpZW50
IGlzIHNwZWNpZmllZCBhcyBhbiBJUCBhZGRyZXNzKHdoaWNoIGNhbiBub3QgYmUgcmVzb2x2ZWQg
YXMgYW4gRlFETiksIGl0IGFjdHVhbGx5IHJldHVybiB0aGUgcmVzdWx0OiBNQ0xfU1VCTkVUV09S
Sy4NCglJIGd1ZXNzIHRoYXQncyB0aGUgcmVhc29uIHRoYXQgdGhlIGNsaWVudCAiMTkyLjE2OC4w
LjIxIiBhbmQgIjE5Mi4xNjguMC4wLzE2IiBib3RoIGFyZSBzb3J0ZWQgdG8gdGhlIHNhbWUgY2F0
ZWdvcnk6IE1DTF9TVUJORVRXT1JLLCBzbyB0aGUgb3JkZXIgb2YgZXhwb3J0cyBtYXR0ZXJzIGhl
cmUuDQoJSXMgdGhpcyB3aGF0IGV4cG9ydGZzIGFuZCBtb3VudGQgbWVhbiB0byBiZT8NCkIuUg0K
TWlubGFuIFdhbmcNCg0KT24gVHVlc2RheSwgT2N0b2JlciAxNSwgMjAxMyBhdCAwMzo0OUFNICsw
MDAwLCBCcnVjZSBGaWVsZHMgd3JvdGU6DQo+IExvb2tpbmcgYXQgdGhlIG1vdW50ZCBjb2RlLi4u
Lg0KPiANCj4gTG9va3MgbGlrZSB1dGlscy9tb3VudGQvY2FjaGUuYyBtYWtlcyBubyBzcGVjaWFs
IGVmZm9ydCB0byBwcmlvcml0aXplDQo+IGV4cG9ydHMgZXhjZXB0IGluIHRoZSB2NHJvb3QgYW5k
IGNyb3NzbW50IGNhc2VzLCBuZWl0aGVyIGFuIGlzc3VlIGluDQo+IHlvdXIgY2FzZS4NCj4gDQo+
IFNvIHllcyBpdCBkZXBlbmRzIG9uIG9yZGVyaW5nLiBGcm9tIG1hbiBleHBvcnRzOg0KPiANCj4g
CSBJZiBhIGNsaWVudCBtYXRjaGVzIG1vcmUgdGhhbiBvbmUgb2YgdGhlIHNwZWNpZmljYXRpb25z
IGFib3ZlLA0KPiAJIHRoZW4gdGhlIGZpcnN0IG1hdGNoIGZyb20gdGhlIGFib3ZlIGxpc3Qgb3Jk
ZXIgdGFrZXMgcHJlY2VkZW5jZQ0KPiAJIC0gcmVnYXJkbGVzcyAgb2YgdGhlICBvcmRlciB0aGV5
IGFwcGVhciBvbiB0aGUgZXhwb3J0IGxpbmUuDQo+IAkgSG93ZXZlciwgaWYgYSBjbGllbnQgbWF0
Y2hlcyBtb3JlIHRoYW4gb25lIG9mIHRoZSBzYW1lIHR5cGUgb2YNCj4gCSBzcGVjaWZpY2F0aW9u
IChlLmcuICB0d28gIG5ldGdyb3VwcyksIHRoZW4gIHRoZSAgZmlyc3QgIG1hdGNoDQo+IAkgZnJv
bSAgdGhlIG9yZGVyIHRoZXkgYXBwZWFyIG9uIHRoZSBleHBvcnQgbGluZSB0YWtlcw0KPiAJIHBy
ZWNlZGVuY2UuDQo+IA0KPiBUaGUgb3JkZXIgZ2l2ZW4gaXM6IHNpbmdsZSBob3N0LCBJUCBuZXR3
b3Jrcywgd2lsZGNhcmRzLCBuZWdyb3VwcywNCj4gYW5vbnltb3VzLg0KPiANCj4gU28gdGhlIHNp
bmdsZSBob3N0IGV4cG9ydHMgc2hvdWxkIGhhdmUgdGFrZW4gcHJlY2VkZW5jZS4NCj4gDQo+IFRo
ZSBjb2RlIGhlcmUgZG9lcyBsb29rIGxpa2UgaXQgY29yZWN0bHkgaW1wbGVtZW50cyB0aGUgYWJv
dmUgb3JkZXJpbmcuDQo+IA0KPiBXaGF0IHZlcnNpb24gb2YgbmZzLXV0aWxzIGFyZSB5b3UgdXNp
bmc/DQo+IA0KPiAtLWIuDQo+IA0KPiBPbiBUdWUsIE9jdCAxNSwgMjAxMyBhdCAwNjozOTo1OUFN
ICswMDAwLCBXYW5nbWlubGFuIHdyb3RlOg0KPiA+IE9uIE1vbiwgT2N0IDE0LCAyMDEzIGF0IDE2
OjQ2ICswMDAwLCBCcnVjZSBGaWVsZHMgd3JvdGU6DQo+ID4gPiBPbiBNb24sIE9jdCAxNCwgMjAx
MyBhdCAwMjoxNjo1OEFNICswMDAwLCBXYW5nbWlubGFuIHdyb3RlOg0KPiA+ID4gPiDjgIDjgIBI
aSwNCj4gPiA+ID4g44CA44CAICAgICAgICAgSeKAmXZlIGdvdCBhIHByb2JsZW0gb24gdGhlIG5m
cyBleHBvcnRmcyBjb21tYW5kLiBJ4oCZbQ0KPiBub3QNCj4gPiA+IHN1cmUgaWYgdGhpcyBpcyB0
aGUgcmlnaHQgcGxhY2UgdG8gYXNrIHRoaXMsIGlmIG5vdCwgY2FuIHlvdSBwbGVhc2UgdGVsbCBt
ZQ0KPiB3aGVyZT8NCj4gPiA+ID4NCj4gPiA+ID4g44CA44CAICAgICAgICAgSGVyZeKAmXMgd2hh
dCBJIG5lZWQ6DQo+ID4gPiA+IOOAgOOAgDEuIEkgaGF2ZSBhIGZvbGRlciBuYW1lZCAvbW50L2Zz
MSB0byBiZSBleHBvcnRlZC4NCj4gPiA+ID4g44CA44CAMi4gQWxsIHRoZSBob3N0IGluIHN1Ym5l
dHdvcmsgMTkyLjE2OC4wLjAvMTYgc2hvdWxkIGJlIGFibGUgYWNjZXNzDQo+IHRoaXMNCj4gPiA+
IGZvbGRlciwgYnV0IHRoZWlyIHJvb3Qgc2hvdWxkIGJlIHNxdWFzaGVkLg0KPiA+ID4gPiDjgIDj
gIAzLiBTb21lIHNwZWNpZmllZCBob3N0IGluIHRoZSBzYW1lIHN1Ym5ldHdvcmsgY2FuIGdhaW4g
dGhlIHJvb3QNCj4gPiA+IHBlcm1pc3Npb24gb24gdGhlIGZvbGRlciwgZm9yIGV4YW1wbGU6IDE5
Mi4xNjguMC4yMSwgMTkyLjE2OC4wLjIyLg0KPiA+ID4gPg0KPiA+ID4gPiDjgIDjgIBJ4oCZdmUg
Z290IGEgU0xFUzExU1AxIGJveCBhcyB0aGUgbmZzIHNlcnZlciwgdGhlIG5mcyBjbGllbnRzIGFy
ZQ0KPiBTTEVTMTFTUDEsDQo+ID4gPiB0b28sIGFuZCB0aGUgcHJvdG9jb2wgdXNlZCBiZXR3ZWVu
IGNsaWVudHMgYW5kIHNlcnZlciBhcmUgTkZTdjMuDQo+ID4gPiA+IOOAgOOAgEhlcmUgYXJlIHRo
ZSBjb21tYW5kcyBJIHVzZWQgdG8gZG8gdGhlIGV4cG9ydDoNCj4gPiA+ID4g44CA44CAI2V4cG9y
dGZzIOKAk28gcncscm9vdF9zcXVhc2ggMTkyLjE2OC4wLjAvMTY6L21udC9mczENCj4gPiA+ID4g
44CA44CAI2V4cG9ydGZzIOKAk28gcncsbm9fcm9vdF9zcXVhc2ggMTkyLjE2OC4wLjIxOi9tbnQv
ZnMxDQo+ID4gPiA+IOOAgOOAgCNleHBvcnRmcyDigJNvIHJ3LG5vX3Jvb3Rfc3F1YXNoIDE5Mi4x
NjguMC4yMjovbW50L2ZzMQ0KPiA+ID4gPiDjgIDjgIBBZnRlciB0aGlzLCBldmVyeXRoaW5nIHdv
cmtzIGFzIGV4cGVjdGVkLg0KPiA+IEFmdGVyIHRoaXMsIHRoZSBjb250ZW50cyBvZiAvcHJvYy9u
ZXQvcnBjL2F1dGgudW5peC5pcC9jb250ZW50IGFuZA0KPiAvcHJvYy9uZXQvcnBjL25mc2QuZXhw
b3J0L2NvbnRlbnQgYXJlOg0KPiA+IAlOVjIwMF8wMTovcHJvYy9uZXQvcnBjICMgY2F0IGF1dGgu
dW5peC5pcC9jb250ZW50DQo+ID4gCSNjbGFzcyBJUCBkb21haW4NCj4gPiAJbmZzZCAxOTIuMTY4
LjAuMjEgMTkyLjE2OC4wLjAvMTYsMTkyLjE2OC4wLjIxDQo+ID4gCW5mc2QgMC4wLjAuMCAtdGVz
dC1jbGllbnQtDQo+ID4gCSMgbmZzZCAxMDAuNDMuMTg5LjEgLW5vLWRvbWFpbi0NCj4gPg0KPiA+
IAlOVjIwMF8wMTovcHJvYy9uZXQvcnBjICMgY2F0IG5mc2QuZXhwb3J0L2NvbnRlbnQNCj4gPiAJ
I3BhdGggZG9tYWluKGZsYWdzKQ0KPiA+IAkvbW50L2ZzMQ0KPiAJLXRlc3QtY2xpZW50LShydyxu
b19yb290X3NxdWFzaCxzeW5jLG5vX3dkZWxheSxmc2lkPTAsYW5vbnVpZD00Mjk0OTY3DQo+IDI5
NSxhbm9uZ2lkPTQyOTQ5NjcyOTUpDQo+ID4gCS9tbnQvZnMxDQo+IAkxOTIuMTY4LjAuMC8xNiwx
OTIuMTY4LjAuMjEocncsbm9fcm9vdF9zcXVhc2gsc3luYyx3ZGVsYXksbm9fc3VidHJlZQ0KPiBf
Y2hlY2ssdXVpZD0xMzI2NmYwZDoxZmJkNDBkNTpiMGI1YzRmZTpjZmUxMDRlYikNCj4gPiAJIyAv
bW50L2ZzMQ0KPiAJMTkyLjE2OC4wLjAvMTYsMTkyLjE2OC4wLjIxKHJ3LG5vX3Jvb3Rfc3F1YXNo
LHN5bmMsd2RlbGF5LG5vX3N1YnRyZWUNCj4gX2NoZWNrLHV1aWQ9MTMyNjZmMGQ6MWZiZDQwZDU6
YjBiNWM0ZmU6Y2ZlMTA0ZWIpDQo+ID4gQmVzaWRlcywgdGhlIGNvbnRlbnQgb2YgL3Zhci9saWIv
bmZzL2V0YWIgaXM6DQo+ID4gCU5WMjAwXzAxOi9wcm9jL25ldC9ycGMgIyBjYXQgL3Zhci9saWIv
bmZzL2V0YWINCj4gPiAJL21udC9mczENCj4gCTE5Mi4xNjguMC4yMihydyxzeW5jLHdkZWxheSxo
aWRlLG5vY3Jvc3NtbnQsc2VjdXJlLG5vX3Jvb3Rfc3F1YXNoLG5vDQo+IF9hbGxfc3F1YXNoLG5v
X3N1YnRyZWVfY2hlY2ssc2VjdXJlX2xvY2tzLGFjbCxhbm9udWlkPTY1NTM0LGFub25naWQ9NjU1
Mw0KPiA0KQ0KPiA+IAkvbW50L2ZzMQ0KPiAJMTkyLjE2OC4wLjIxKHJ3LHN5bmMsd2RlbGF5LGhp
ZGUsbm9jcm9zc21udCxzZWN1cmUsbm9fcm9vdF9zcXVhc2gsbm8NCj4gX2FsbF9zcXVhc2gsbm9f
c3VidHJlZV9jaGVjayxzZWN1cmVfbG9ja3MsYWNsLGFub251aWQ9NjU1MzQsYW5vbmdpZD02NTUz
DQo+IDQpDQo+ID4gCS9tbnQvZnMxDQo+IAkxOTIuMTY4LjAuMC8xNihydyxzeW5jLHdkZWxheSxo
aWRlLG5vY3Jvc3NtbnQsc2VjdXJlLHJvb3Rfc3F1YXNoLG5vXw0KPiBhbGxfc3F1YXNoLG5vX3N1
YnRyZWVfY2hlY2ssc2VjdXJlX2xvY2tzLGFjbCxhbm9udWlkPTY1NTM0LGFub25naWQ9NjU1MzQN
Cj4gKQ0KPiA+ID4gPg0KPiA+ID4gPiDjgIDjgIBCdXQsIGFmdGVyIHRoZSBmb2xsb3dpbmcgb3Bl
cmF0aW9uczoNCj4gPiA+ID4g44CA44CAI2V4cG9ydGZzIOKAk3UgMTkyLjE2OC4wLjAvMTY6L21u
dC9mczEgICAgICAgICAgICAgIC8qIERlbGV0ZQ0KPiB0aGlzDQo+ID4gPiBleHBvcnQgKi8NCj4g
PiA+ID4g44CA44CAIyBleHBvcnRmcyDigJNvIHJ3LHJvb3Rfc3F1YXNoIDE5Mi4xNjguMC4wLzE2
Oi9tbnQvZnMxDQo+IC8qDQo+ID4gPiBBbmQgYWRkIGl0IGFnYWluICovDQo+ID4gPiA+IOOAgOOA
gEhvc3RzIG9uIDE5Mi4xNjguMC4yMSBhbmQgMTkyLjE2OC4wLjIyIGRvZXNu4oCZdCBnZXQgcm9v
dA0KPiBwZXJtaXNzaW9uDQo+ID4gPiBhbnkgbW9yZS4gd2hlbiBJIHRyaWVkIHRvIHdyaXRlIGEg
ZmlsZSwgaXQgY29tcGxhaW5zIGFib3V0IOKAnFBlcm1pc3Npb24NCj4gZGVuaWVk4oCdLg0KPiA+
ID4gPg0KPiA+ID4gPiDjgIDjgIBTbywgZG9lcyB0aGUgb3JkZXIgb2YgZXhwb3J0ZnMgY29tbWFu
ZCBoYXMgc29tZXRoaW5nIHRvIGRvIHRoZQ0KPiBmaW5hbA0KPiA+ID4gcmVzdWx0PyBPciBhbSBJ
IGRvaW5nIHNvbWV0aGluZyB3cm9uZz8NCj4gPiBBZnRlciB0aGlzLCB0aGUgY29udGVudHMgb2Yg
L3Byb2MvbmV0L3JwYy9hdXRoLnVuaXguaXAvY29udGVudCBhbmQNCj4gL3Byb2MvbmV0L3JwYy9u
ZnNkLmV4cG9ydC9jb250ZW50IGFyZToNCj4gPiAJTlYyMDBfMDE6L3Byb2MvbmV0L3JwYyAjIGNh
dCBhdXRoLnVuaXguaXAvY29udGVudA0KPiA+IAkjY2xhc3MgSVAgZG9tYWluDQo+ID4gCW5mc2Qg
MTkyLjE2OC4wLjIxIDE5Mi4xNjguMC4wLzE2LDE5Mi4xNjguMC4yMQ0KPiA+IAluZnNkIDAuMC4w
LjAgLXRlc3QtY2xpZW50LQ0KPiA+IAkjIG5mc2QgMTAwLjQzLjE4OS4xIC1uby1kb21haW4tDQo+
ID4NCj4gPiAJTlYyMDBfMDE6L3Byb2MvbmV0L3JwYyAjIGNhdCBuZnNkDQo+ID4gCW5mc2QgICAg
ICAgICBuZnNkLmV4cG9ydC8gbmZzZC5maC8NCj4gPiAJTlYyMDBfMDE6L3Byb2MvbmV0L3JwYyAj
IGNhdCBuZnNkDQo+ID4gCW5mc2QgICAgICAgICBuZnNkLmV4cG9ydC8gbmZzZC5maC8NCj4gPiAJ
TlYyMDBfMDE6L3Byb2MvbmV0L3JwYyAjIGNhdCBuZnNkLmV4cG9ydC9jb250ZW50DQo+ID4gCSNw
YXRoIGRvbWFpbihmbGFncykNCj4gPiAJL21udC9mczENCj4gCS10ZXN0LWNsaWVudC0ocncsbm9f
cm9vdF9zcXVhc2gsc3luYyxub193ZGVsYXksZnNpZD0wLGFub251aWQ9NDI5NDk2Nw0KPiAyOTUs
YW5vbmdpZD00Mjk0OTY3Mjk1KQ0KPiA+IAkvbW50L2ZzMQ0KPiAJMTkyLjE2OC4wLjAvMTYsMTky
LjE2OC4wLjIxKHJ3LHJvb3Rfc3F1YXNoLHN5bmMsd2RlbGF5LG5vX3N1YnRyZWVfY2gNCj4gZWNr
LHV1aWQ9MTMyNjZmMGQ6MWZiZDQwZDU6YjBiNWM0ZmU6Y2ZlMTA0ZWIpDQo+ID4gQW5kIHRoZSBj
b250ZW50IG9mIC92YXIvbGliL25mcy9ldGFiIGlzOg0KPiA+IAlOVjIwMF8wMTovcHJvYy9uZXQv
cnBjICMgY2F0IC92YXIvbGliL25mcy9ldGFiDQo+ID4gCS9tbnQvZnMxDQo+IAkxOTIuMTY4LjAu
MC8xNihydyxzeW5jLHdkZWxheSxoaWRlLG5vY3Jvc3NtbnQsc2VjdXJlLHJvb3Rfc3F1YXNoLG5v
Xw0KPiBhbGxfc3F1YXNoLG5vX3N1YnRyZWVfY2hlY2ssc2VjdXJlX2xvY2tzLGFjbCxhbm9udWlk
PTY1NTM0LGFub25naWQ9NjU1MzQNCj4gKQ0KPiA+IAkvbW50L2ZzMQ0KPiAJMTkyLjE2OC4wLjIy
KHJ3LHN5bmMsd2RlbGF5LGhpZGUsbm9jcm9zc21udCxzZWN1cmUsbm9fcm9vdF9zcXVhc2gsbm8N
Cj4gX2FsbF9zcXVhc2gsbm9fc3VidHJlZV9jaGVjayxzZWN1cmVfbG9ja3MsYWNsLGFub251aWQ9
NjU1MzQsYW5vbmdpZD02NTUzDQo+IDQpDQo+ID4gCS9tbnQvZnMxDQo+IAkxOTIuMTY4LjAuMjEo
cncsc3luYyx3ZGVsYXksaGlkZSxub2Nyb3NzbW50LHNlY3VyZSxub19yb290X3NxdWFzaCxubw0K
PiBfYWxsX3NxdWFzaCxub19zdWJ0cmVlX2NoZWNrLHNlY3VyZV9sb2NrcyxhY2wsYW5vbnVpZD02
NTUzNCxhbm9uZ2lkPTY1NTMNCj4gNCkNCj4gPiA+DQo+ID4gPiBUaGF0IHNvdW5kcyBsaWtlIGEg
YnVnLiAgVGhlIGNvbnRlbnRzIG9mDQo+ID4gPiAvcHJvYy9uZXQvcnBjL2F1dGgudW5peC5pcC9j
b250ZW50IGFuZCAvcHJvYy9uZXQvcnBjL25mc2QuZXhwb3J0L2NvbnRlbnQNCj4gPiA+IGFmdGVy
IGdldHRpbmcgdGhlIGFib3ZlICJwZXJtaXNzaW9uIGRlbmllZCIgbWlnaHQgYmUgaW50ZXJlc3Rp
bmcuDQo=
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-16 1:22 ` Wangminlan
@ 2013-10-17 7:16 ` Wangminlan
2013-10-17 13:14 ` Chuck Lever
2013-10-17 13:16 ` J. Bruce Fields
0 siblings, 2 replies; 13+ messages in thread
From: Wangminlan @ 2013-10-17 7:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-nfs
SGksIA0KCUkgd2VudCB0aHJvdWdoIHRoZSBjb2RlIG9mIG5mcy11dGlscywgY2hlY2sgdGhlIGZ1
bmN0aW9uIGNsaWVudF9nZXR0eXBlIGluIHN1cHBvcnQvZXhwb3J0L2NsaWVudC5jOg0KaW4gbmZz
LXV0aWxzLTEtMi05LXJjNiwgYW5kIGluIG5mcy11dGlscy0xLjIuNiwgdGhleSBoYXZlIHRoaXMg
aW1wbGVtZW50YXRpb24gaW4gdGhlIGZpbmFsIHBhcnQ6DQogNzcwICAgICAgICAgLyoNCiA3NzEg
ICAgICAgICAgKiBUcmVhdCB1bmFkb3JuZWQgSVAgYWRkcmVzc2VzIGFzIE1DTF9TVUJORVRXT1JL
Lg0KIDc3MiAgICAgICAgICAqIEV2ZXJ5dGhpbmcgZWxzZSBpcyBNQ0xfRlFETi4NCiA3NzMgICAg
ICAgICAgKi8NCiA3NzQgICAgICAgICBhaSA9IGhvc3RfcHRvbihpZGVudCk7DQogNzc1ICAgICAg
ICAgaWYgKGFpICE9IE5VTEwpIHsNCiA3NzYgICAgICAgICAgICAgICAgIGZyZWVhZGRyaW5mbyhh
aSk7DQogNzc3ICAgICAgICAgICAgICAgICByZXR1cm4gTUNMX1NVQk5FVFdPUks7DQogNzc4ICAg
ICAgICAgfQ0KIDc3OSANCiA3ODAgICAgICAgICByZXR1cm4gTUNMX0ZRRE47DQogNzgxIH0NCg0K
d2hpbGUgYmFjayBpbiBkYXlzIG9mIG5mcy11dGlscy0xLjAuNzogY2xpZW50X2dldHR5cGUgbG9v
a3MgbGlrZSB0aGlzOg0KIDI3NyBjbGllbnRfZ2V0dHlwZShjaGFyICppZGVudCkNCiAyNzggew0K
IDI3OSAgICAgICAgIGNoYXIgICAgKnNwOw0KIDI4MCANCiAyODEgICAgICAgICBpZiAoaWRlbnRb
MF0gPT0gJ1wwJykNCiAyODIgICAgICAgICAgICAgICAgIHJldHVybiBNQ0xfQU5PTllNT1VTOw0K
IDI4MyAgICAgICAgIGlmIChpZGVudFswXSA9PSAnQCcpIHsNCiAyODQgI2lmbmRlZiBIQVZFX0lO
TkVUR1INCiAyODUgICAgICAgICAgICAgICAgIHhsb2coTF9XQVJOSU5HLCAibmV0Z3JvdXAgc3Vw
cG9ydCBub3QgY29tcGlsZWQgaW4iKTsNCiAyODYgI2VuZGlmDQogMjg3ICAgICAgICAgICAgICAg
ICByZXR1cm4gTUNMX05FVEdST1VQOw0KIDI4OCAgICAgICAgIH0NCiAyODkgICAgICAgICBmb3Ig
KHNwID0gaWRlbnQ7ICpzcDsgc3ArKykgew0KIDI5MCAgICAgICAgICAgICAgICAgaWYgKCpzcCA9
PSAnKicgfHwgKnNwID09ICc/JyB8fCAqc3AgPT0gJ1snKQ0KIDI5MSAgICAgICAgICAgICAgICAg
ICAgICAgICByZXR1cm4gTUNMX1dJTERDQVJEOw0KIDI5MiAgICAgICAgICAgICAgICAgaWYgKCpz
cCA9PSAnLycpDQogMjkzICAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiBNQ0xfU1VCTkVU
V09SSzsNCiAyOTQgICAgICAgICAgICAgICAgIGlmICgqc3AgPT0gJ1xcJyAmJiBzcFsxXSkNCiAy
OTUgICAgICAgICAgICAgICAgICAgICAgICAgc3ArKzsNCiAyOTYgICAgICAgICB9DQogMjk3ICAg
ICAgICAgcmV0dXJuIE1DTF9GUUROOw0KIDI5OCB9DQoNCkl0J3Mgc2ltcGxlLCBhbmQgY2xpZW50
IGxpa2UgIjE5Mi4xNjguMC4yMSIgaXMgdHJlYXRlZCBhcyBNQ0xfRlFETi4gDQpJIHRyaWVkIHRo
ZSBzYW1lIG9wZXJhdGlvbiBpbiB0aGlzIHZlcnNpb24sIHRoZXJlJ3Mgbm8gc3VjaCBwcm9ibGVt
IGFzIGluIG5mcy11dGlscy0xLjIuMSBhbmQgbmZzLXV0aWxzLTEuMi42Lg0KDQo+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxpbnV4LW5mcy1vd25lckB2Z2VyLmtlcm5lbC5v
cmcNCj4gW21haWx0bzpsaW51eC1uZnMtb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYg
T2YgV2FuZ21pbmxhbg0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTYsIDIwMTMgOToyMyBB
TQ0KPiBUbzogSi4gQnJ1Y2UgRmllbGRzDQo+IENjOiBsaW51eC1uZnNAdmdlci5rZXJuZWwub3Jn
DQo+IFN1YmplY3Q6IFJFOiBEaWZmZXJlbnQgc2VxdWVuY2Ugb2YgImV4cG9ydGZzIiBwcm9kdWNl
IGRpZmZlcmVudCBlZmZlY3RzIG9uIG5mcw0KPiBjbGllbnQgbW91bnRzDQo+IA0KPiBIaSwgQnJ1
Y2UsDQo+IAlUaGUgbmZzLXV0aWxzIG9uIG15IGJveCBpcyBuZnMtdXRpbHMtMS4yLjEtMi42LjYs
IHdoaWNoIGlzIFN1c2UgZGlzdHJpYnV0ZWQuDQo+IAlJIHRyaWVkIHRoZSBzYW1lIGV4cGVyaW1l
bnQgb24gZmVkb3JhMTgsIHdoaWNoIHVzZSBuZnMtdXRpbHMtMS4yLjYsIGFuZA0KPiBnb3QgdGhl
IHNhbWUgcmVzdWx0Lg0KPiAJSSBnbyB0aHJvdWdoIHRoZSBjb2RlIG9mIHN1cHBvcnQvZXhwb3J0
L2NsaWVudC5jLCBmb3VuZCB0aGF0IGluDQo+IGNsaWVudF9nZXRfdHlwZSgpLCB3aGVuIHRoZSBj
bGllbnQgaXMgc3BlY2lmaWVkIGFzIGFuIElQIGFkZHJlc3Mod2hpY2ggY2FuIG5vdA0KPiBiZSBy
ZXNvbHZlZCBhcyBhbiBGUUROKSwgaXQgYWN0dWFsbHkgcmV0dXJuIHRoZSByZXN1bHQ6IE1DTF9T
VUJORVRXT1JLLg0KPiAJSSBndWVzcyB0aGF0J3MgdGhlIHJlYXNvbiB0aGF0IHRoZSBjbGllbnQg
IjE5Mi4xNjguMC4yMSIgYW5kDQo+ICIxOTIuMTY4LjAuMC8xNiIgYm90aCBhcmUgc29ydGVkIHRv
IHRoZSBzYW1lIGNhdGVnb3J5OiBNQ0xfU1VCTkVUV09SSywNCj4gc28gdGhlIG9yZGVyIG9mIGV4
cG9ydHMgbWF0dGVycyBoZXJlLg0KPiAJSXMgdGhpcyB3aGF0IGV4cG9ydGZzIGFuZCBtb3VudGQg
bWVhbiB0byBiZT8NCj4gQi5SDQo+IE1pbmxhbiBXYW5nDQo+IA0KPiBPbiBUdWVzZGF5LCBPY3Rv
YmVyIDE1LCAyMDEzIGF0IDAzOjQ5QU0gKzAwMDAsIEJydWNlIEZpZWxkcyB3cm90ZToNCj4gPiBM
b29raW5nIGF0IHRoZSBtb3VudGQgY29kZS4uLi4NCj4gPg0KPiA+IExvb2tzIGxpa2UgdXRpbHMv
bW91bnRkL2NhY2hlLmMgbWFrZXMgbm8gc3BlY2lhbCBlZmZvcnQgdG8gcHJpb3JpdGl6ZQ0KPiA+
IGV4cG9ydHMgZXhjZXB0IGluIHRoZSB2NHJvb3QgYW5kIGNyb3NzbW50IGNhc2VzLCBuZWl0aGVy
IGFuIGlzc3VlIGluDQo+ID4geW91ciBjYXNlLg0KPiA+DQo+ID4gU28geWVzIGl0IGRlcGVuZHMg
b24gb3JkZXJpbmcuIEZyb20gbWFuIGV4cG9ydHM6DQo+ID4NCj4gPiAJIElmIGEgY2xpZW50IG1h
dGNoZXMgbW9yZSB0aGFuIG9uZSBvZiB0aGUgc3BlY2lmaWNhdGlvbnMgYWJvdmUsDQo+ID4gCSB0
aGVuIHRoZSBmaXJzdCBtYXRjaCBmcm9tIHRoZSBhYm92ZSBsaXN0IG9yZGVyIHRha2VzIHByZWNl
ZGVuY2UNCj4gPiAJIC0gcmVnYXJkbGVzcyAgb2YgdGhlICBvcmRlciB0aGV5IGFwcGVhciBvbiB0
aGUgZXhwb3J0IGxpbmUuDQo+ID4gCSBIb3dldmVyLCBpZiBhIGNsaWVudCBtYXRjaGVzIG1vcmUg
dGhhbiBvbmUgb2YgdGhlIHNhbWUgdHlwZSBvZg0KPiA+IAkgc3BlY2lmaWNhdGlvbiAoZS5nLiAg
dHdvICBuZXRncm91cHMpLCB0aGVuICB0aGUgIGZpcnN0ICBtYXRjaA0KPiA+IAkgZnJvbSAgdGhl
IG9yZGVyIHRoZXkgYXBwZWFyIG9uIHRoZSBleHBvcnQgbGluZSB0YWtlcw0KPiA+IAkgcHJlY2Vk
ZW5jZS4NCj4gPg0KPiA+IFRoZSBvcmRlciBnaXZlbiBpczogc2luZ2xlIGhvc3QsIElQIG5ldHdv
cmtzLCB3aWxkY2FyZHMsIG5lZ3JvdXBzLA0KPiA+IGFub255bW91cy4NCj4gPg0KPiA+IFNvIHRo
ZSBzaW5nbGUgaG9zdCBleHBvcnRzIHNob3VsZCBoYXZlIHRha2VuIHByZWNlZGVuY2UuDQo+ID4N
Cj4gPiBUaGUgY29kZSBoZXJlIGRvZXMgbG9vayBsaWtlIGl0IGNvcmVjdGx5IGltcGxlbWVudHMg
dGhlIGFib3ZlIG9yZGVyaW5nLg0KPiA+DQo+ID4gV2hhdCB2ZXJzaW9uIG9mIG5mcy11dGlscyBh
cmUgeW91IHVzaW5nPw0KPiA+DQo+ID4gLS1iLg0KPiA+DQo+ID4gT24gVHVlLCBPY3QgMTUsIDIw
MTMgYXQgMDY6Mzk6NTlBTSArMDAwMCwgV2FuZ21pbmxhbiB3cm90ZToNCj4gPiA+IE9uIE1vbiwg
T2N0IDE0LCAyMDEzIGF0IDE2OjQ2ICswMDAwLCBCcnVjZSBGaWVsZHMgd3JvdGU6DQo+ID4gPiA+
IE9uIE1vbiwgT2N0IDE0LCAyMDEzIGF0IDAyOjE2OjU4QU0gKzAwMDAsIFdhbmdtaW5sYW4gd3Jv
dGU6DQo+ID4gPiA+ID4g44CA44CASGksDQo+ID4gPiA+ID4g44CA44CAICAgICAgICAgSeKAmXZl
IGdvdCBhIHByb2JsZW0gb24gdGhlIG5mcyBleHBvcnRmcyBjb21tYW5kLiBJ4oCZbQ0KPiA+IG5v
dA0KPiA+ID4gPiBzdXJlIGlmIHRoaXMgaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIGFzayB0aGlzLCBp
ZiBub3QsIGNhbiB5b3UgcGxlYXNlIHRlbGwgbWUNCj4gPiB3aGVyZT8NCj4gPiA+ID4gPg0KPiA+
ID4gPiA+IOOAgOOAgCAgICAgICAgIEhlcmXigJlzIHdoYXQgSSBuZWVkOg0KPiA+ID4gPiA+IOOA
gOOAgDEuIEkgaGF2ZSBhIGZvbGRlciBuYW1lZCAvbW50L2ZzMSB0byBiZSBleHBvcnRlZC4NCj4g
PiA+ID4gPiDjgIDjgIAyLiBBbGwgdGhlIGhvc3QgaW4gc3VibmV0d29yayAxOTIuMTY4LjAuMC8x
NiBzaG91bGQgYmUgYWJsZSBhY2Nlc3MNCj4gPiB0aGlzDQo+ID4gPiA+IGZvbGRlciwgYnV0IHRo
ZWlyIHJvb3Qgc2hvdWxkIGJlIHNxdWFzaGVkLg0KPiA+ID4gPiA+IOOAgOOAgDMuIFNvbWUgc3Bl
Y2lmaWVkIGhvc3QgaW4gdGhlIHNhbWUgc3VibmV0d29yayBjYW4gZ2FpbiB0aGUgcm9vdA0KPiA+
ID4gPiBwZXJtaXNzaW9uIG9uIHRoZSBmb2xkZXIsIGZvciBleGFtcGxlOiAxOTIuMTY4LjAuMjEs
IDE5Mi4xNjguMC4yMi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IOOAgOOAgEnigJl2ZSBnb3QgYSBT
TEVTMTFTUDEgYm94IGFzIHRoZSBuZnMgc2VydmVyLCB0aGUgbmZzIGNsaWVudHMgYXJlDQo+ID4g
U0xFUzExU1AxLA0KPiA+ID4gPiB0b28sIGFuZCB0aGUgcHJvdG9jb2wgdXNlZCBiZXR3ZWVuIGNs
aWVudHMgYW5kIHNlcnZlciBhcmUgTkZTdjMuDQo+ID4gPiA+ID4g44CA44CASGVyZSBhcmUgdGhl
IGNvbW1hbmRzIEkgdXNlZCB0byBkbyB0aGUgZXhwb3J0Og0KPiA+ID4gPiA+IOOAgOOAgCNleHBv
cnRmcyDigJNvIHJ3LHJvb3Rfc3F1YXNoIDE5Mi4xNjguMC4wLzE2Oi9tbnQvZnMxDQo+ID4gPiA+
ID4g44CA44CAI2V4cG9ydGZzIOKAk28gcncsbm9fcm9vdF9zcXVhc2ggMTkyLjE2OC4wLjIxOi9t
bnQvZnMxDQo+ID4gPiA+ID4g44CA44CAI2V4cG9ydGZzIOKAk28gcncsbm9fcm9vdF9zcXVhc2gg
MTkyLjE2OC4wLjIyOi9tbnQvZnMxDQo+ID4gPiA+ID4g44CA44CAQWZ0ZXIgdGhpcywgZXZlcnl0
aGluZyB3b3JrcyBhcyBleHBlY3RlZC4NCj4gPiA+IEFmdGVyIHRoaXMsIHRoZSBjb250ZW50cyBv
ZiAvcHJvYy9uZXQvcnBjL2F1dGgudW5peC5pcC9jb250ZW50IGFuZA0KPiA+IC9wcm9jL25ldC9y
cGMvbmZzZC5leHBvcnQvY29udGVudCBhcmU6DQo+ID4gPiAJTlYyMDBfMDE6L3Byb2MvbmV0L3Jw
YyAjIGNhdCBhdXRoLnVuaXguaXAvY29udGVudA0KPiA+ID4gCSNjbGFzcyBJUCBkb21haW4NCj4g
PiA+IAluZnNkIDE5Mi4xNjguMC4yMSAxOTIuMTY4LjAuMC8xNiwxOTIuMTY4LjAuMjENCj4gPiA+
IAluZnNkIDAuMC4wLjAgLXRlc3QtY2xpZW50LQ0KPiA+ID4gCSMgbmZzZCAxMDAuNDMuMTg5LjEg
LW5vLWRvbWFpbi0NCj4gPiA+DQo+ID4gPiAJTlYyMDBfMDE6L3Byb2MvbmV0L3JwYyAjIGNhdCBu
ZnNkLmV4cG9ydC9jb250ZW50DQo+ID4gPiAJI3BhdGggZG9tYWluKGZsYWdzKQ0KPiA+ID4gCS9t
bnQvZnMxDQo+ID4gCS10ZXN0LWNsaWVudC0ocncsbm9fcm9vdF9zcXVhc2gsc3luYyxub193ZGVs
YXksZnNpZD0wLGFub251aWQ9NDI5NDk2Nw0KPiA+IDI5NSxhbm9uZ2lkPTQyOTQ5NjcyOTUpDQo+
ID4gPiAJL21udC9mczENCj4gPiAJMTkyLjE2OC4wLjAvMTYsMTkyLjE2OC4wLjIxKHJ3LG5vX3Jv
b3Rfc3F1YXNoLHN5bmMsd2RlbGF5LG5vX3N1YnRyZWUNCj4gPiBfY2hlY2ssdXVpZD0xMzI2NmYw
ZDoxZmJkNDBkNTpiMGI1YzRmZTpjZmUxMDRlYikNCj4gPiA+IAkjIC9tbnQvZnMxDQo+ID4gCTE5
Mi4xNjguMC4wLzE2LDE5Mi4xNjguMC4yMShydyxub19yb290X3NxdWFzaCxzeW5jLHdkZWxheSxu
b19zdWJ0cmVlDQo+ID4gX2NoZWNrLHV1aWQ9MTMyNjZmMGQ6MWZiZDQwZDU6YjBiNWM0ZmU6Y2Zl
MTA0ZWIpDQo+ID4gPiBCZXNpZGVzLCB0aGUgY29udGVudCBvZiAvdmFyL2xpYi9uZnMvZXRhYiBp
czoNCj4gPiA+IAlOVjIwMF8wMTovcHJvYy9uZXQvcnBjICMgY2F0IC92YXIvbGliL25mcy9ldGFi
DQo+ID4gPiAJL21udC9mczENCj4gPiAJMTkyLjE2OC4wLjIyKHJ3LHN5bmMsd2RlbGF5LGhpZGUs
bm9jcm9zc21udCxzZWN1cmUsbm9fcm9vdF9zcXVhc2gsbm8NCj4gPg0KPiBfYWxsX3NxdWFzaCxu
b19zdWJ0cmVlX2NoZWNrLHNlY3VyZV9sb2NrcyxhY2wsYW5vbnVpZD02NTUzNCxhbm9uZ2lkPTY1
NTMNCj4gPiA0KQ0KPiA+ID4gCS9tbnQvZnMxDQo+ID4gCTE5Mi4xNjguMC4yMShydyxzeW5jLHdk
ZWxheSxoaWRlLG5vY3Jvc3NtbnQsc2VjdXJlLG5vX3Jvb3Rfc3F1YXNoLG5vDQo+ID4NCj4gX2Fs
bF9zcXVhc2gsbm9fc3VidHJlZV9jaGVjayxzZWN1cmVfbG9ja3MsYWNsLGFub251aWQ9NjU1MzQs
YW5vbmdpZD02NTUzDQo+ID4gNCkNCj4gPiA+IAkvbW50L2ZzMQ0KPiA+IAkxOTIuMTY4LjAuMC8x
NihydyxzeW5jLHdkZWxheSxoaWRlLG5vY3Jvc3NtbnQsc2VjdXJlLHJvb3Rfc3F1YXNoLG5vXw0K
PiA+DQo+IGFsbF9zcXVhc2gsbm9fc3VidHJlZV9jaGVjayxzZWN1cmVfbG9ja3MsYWNsLGFub251
aWQ9NjU1MzQsYW5vbmdpZD02NTUzNA0KPiA+ICkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IOOAgOOA
gEJ1dCwgYWZ0ZXIgdGhlIGZvbGxvd2luZyBvcGVyYXRpb25zOg0KPiA+ID4gPiA+IOOAgOOAgCNl
eHBvcnRmcyDigJN1IDE5Mi4xNjguMC4wLzE2Oi9tbnQvZnMxICAgICAgICAgICAgICAvKiBEZWxl
dGUNCj4gPiB0aGlzDQo+ID4gPiA+IGV4cG9ydCAqLw0KPiA+ID4gPiA+IOOAgOOAgCMgZXhwb3J0
ZnMg4oCTbyBydyxyb290X3NxdWFzaCAxOTIuMTY4LjAuMC8xNjovbW50L2ZzMQ0KPiA+IC8qDQo+
ID4gPiA+IEFuZCBhZGQgaXQgYWdhaW4gKi8NCj4gPiA+ID4gPiDjgIDjgIBIb3N0cyBvbiAxOTIu
MTY4LjAuMjEgYW5kIDE5Mi4xNjguMC4yMiBkb2VzbuKAmXQgZ2V0IHJvb3QNCj4gPiBwZXJtaXNz
aW9uDQo+ID4gPiA+IGFueSBtb3JlLiB3aGVuIEkgdHJpZWQgdG8gd3JpdGUgYSBmaWxlLCBpdCBj
b21wbGFpbnMgYWJvdXQg4oCcUGVybWlzc2lvbg0KPiA+IGRlbmllZOKAnS4NCj4gPiA+ID4gPg0K
PiA+ID4gPiA+IOOAgOOAgFNvLCBkb2VzIHRoZSBvcmRlciBvZiBleHBvcnRmcyBjb21tYW5kIGhh
cyBzb21ldGhpbmcgdG8gZG8gdGhlDQo+ID4gZmluYWwNCj4gPiA+ID4gcmVzdWx0PyBPciBhbSBJ
IGRvaW5nIHNvbWV0aGluZyB3cm9uZz8NCj4gPiA+IEFmdGVyIHRoaXMsIHRoZSBjb250ZW50cyBv
ZiAvcHJvYy9uZXQvcnBjL2F1dGgudW5peC5pcC9jb250ZW50IGFuZA0KPiA+IC9wcm9jL25ldC9y
cGMvbmZzZC5leHBvcnQvY29udGVudCBhcmU6DQo+ID4gPiAJTlYyMDBfMDE6L3Byb2MvbmV0L3Jw
YyAjIGNhdCBhdXRoLnVuaXguaXAvY29udGVudA0KPiA+ID4gCSNjbGFzcyBJUCBkb21haW4NCj4g
PiA+IAluZnNkIDE5Mi4xNjguMC4yMSAxOTIuMTY4LjAuMC8xNiwxOTIuMTY4LjAuMjENCj4gPiA+
IAluZnNkIDAuMC4wLjAgLXRlc3QtY2xpZW50LQ0KPiA+ID4gCSMgbmZzZCAxMDAuNDMuMTg5LjEg
LW5vLWRvbWFpbi0NCj4gPiA+DQo+ID4gPiAJTlYyMDBfMDE6L3Byb2MvbmV0L3JwYyAjIGNhdCBu
ZnNkDQo+ID4gPiAJbmZzZCAgICAgICAgIG5mc2QuZXhwb3J0LyBuZnNkLmZoLw0KPiA+ID4gCU5W
MjAwXzAxOi9wcm9jL25ldC9ycGMgIyBjYXQgbmZzZA0KPiA+ID4gCW5mc2QgICAgICAgICBuZnNk
LmV4cG9ydC8gbmZzZC5maC8NCj4gPiA+IAlOVjIwMF8wMTovcHJvYy9uZXQvcnBjICMgY2F0IG5m
c2QuZXhwb3J0L2NvbnRlbnQNCj4gPiA+IAkjcGF0aCBkb21haW4oZmxhZ3MpDQo+ID4gPiAJL21u
dC9mczENCj4gPiAJLXRlc3QtY2xpZW50LShydyxub19yb290X3NxdWFzaCxzeW5jLG5vX3dkZWxh
eSxmc2lkPTAsYW5vbnVpZD00Mjk0OTY3DQo+ID4gMjk1LGFub25naWQ9NDI5NDk2NzI5NSkNCj4g
PiA+IAkvbW50L2ZzMQ0KPiA+IAkxOTIuMTY4LjAuMC8xNiwxOTIuMTY4LjAuMjEocncscm9vdF9z
cXVhc2gsc3luYyx3ZGVsYXksbm9fc3VidHJlZV9jaA0KPiA+IGVjayx1dWlkPTEzMjY2ZjBkOjFm
YmQ0MGQ1OmIwYjVjNGZlOmNmZTEwNGViKQ0KPiA+ID4gQW5kIHRoZSBjb250ZW50IG9mIC92YXIv
bGliL25mcy9ldGFiIGlzOg0KPiA+ID4gCU5WMjAwXzAxOi9wcm9jL25ldC9ycGMgIyBjYXQgL3Zh
ci9saWIvbmZzL2V0YWINCj4gPiA+IAkvbW50L2ZzMQ0KPiA+IAkxOTIuMTY4LjAuMC8xNihydyxz
eW5jLHdkZWxheSxoaWRlLG5vY3Jvc3NtbnQsc2VjdXJlLHJvb3Rfc3F1YXNoLG5vXw0KPiA+DQo+
IGFsbF9zcXVhc2gsbm9fc3VidHJlZV9jaGVjayxzZWN1cmVfbG9ja3MsYWNsLGFub251aWQ9NjU1
MzQsYW5vbmdpZD02NTUzNA0KPiA+ICkNCj4gPiA+IAkvbW50L2ZzMQ0KPiA+IAkxOTIuMTY4LjAu
MjIocncsc3luYyx3ZGVsYXksaGlkZSxub2Nyb3NzbW50LHNlY3VyZSxub19yb290X3NxdWFzaCxu
bw0KPiA+DQo+IF9hbGxfc3F1YXNoLG5vX3N1YnRyZWVfY2hlY2ssc2VjdXJlX2xvY2tzLGFjbCxh
bm9udWlkPTY1NTM0LGFub25naWQ9NjU1Mw0KPiA+IDQpDQo+ID4gPiAJL21udC9mczENCj4gPiAJ
MTkyLjE2OC4wLjIxKHJ3LHN5bmMsd2RlbGF5LGhpZGUsbm9jcm9zc21udCxzZWN1cmUsbm9fcm9v
dF9zcXVhc2gsbm8NCj4gPg0KPiBfYWxsX3NxdWFzaCxub19zdWJ0cmVlX2NoZWNrLHNlY3VyZV9s
b2NrcyxhY2wsYW5vbnVpZD02NTUzNCxhbm9uZ2lkPTY1NTMNCj4gPiA0KQ0KPiA+ID4gPg0KPiA+
ID4gPiBUaGF0IHNvdW5kcyBsaWtlIGEgYnVnLiAgVGhlIGNvbnRlbnRzIG9mDQo+ID4gPiA+IC9w
cm9jL25ldC9ycGMvYXV0aC51bml4LmlwL2NvbnRlbnQgYW5kDQo+IC9wcm9jL25ldC9ycGMvbmZz
ZC5leHBvcnQvY29udGVudA0KPiA+ID4gPiBhZnRlciBnZXR0aW5nIHRoZSBhYm92ZSAicGVybWlz
c2lvbiBkZW5pZWQiIG1pZ2h0IGJlIGludGVyZXN0aW5nLg0KPiAT77+977+97Lm7HO+/vSbvv71+
77+9Ju+/vRjvv73vv70rLe+/ve+/vd22F++/ve+/vXfvv73vv73Lm++/ve+/ve+/vW3vv71i77+9
77+9Z37Ip++/vRfvv73vv73cqH3vv73vv73vv73GoHrvv70majordu+/ve+/ve+/vQ0KPiAN77+9
77+977+977+9elor77+977+9K3pm77+977+977+9aO+/ve+/ve+/vX7vv73vv73vv73vv71p77+9
77+977+9eu+/vR7vv71377+977+977+9P++/ve+/ve+/ve+/vSbvv70p36IbZg0K
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-17 7:16 ` Wangminlan
@ 2013-10-17 13:14 ` Chuck Lever
2013-10-17 13:18 ` J. Bruce Fields
2013-10-17 21:32 ` NeilBrown
2013-10-17 13:16 ` J. Bruce Fields
1 sibling, 2 replies; 13+ messages in thread
From: Chuck Lever @ 2013-10-17 13:14 UTC (permalink / raw)
To: Wangminlan, Neil Brown; +Cc: J. Bruce Fields, linux-nfs
Hi-
281 if (ident[0] == '\0')
282 return MCL_ANONYMOUS;
283 if (ident[0] == '@') {
284 #ifndef HAVE_INNETGR
285 xlog(L_WARNING, "netgroup support not compiled in");
286 #endif
287 return MCL_NETGROUP;
288 }
289 for (sp = ident; *sp; sp++) {
290 if (*sp == '*' || *sp == '?' || *sp == '[')
291 return MCL_WILDCARD;
292 if (*sp == '/')
293 return MCL_SUBNETWORK;
294 if (*sp == '\\' && sp[1])
295 sp++;
296 }
is still in play today. The "host_pton()" code you posted was added by commit 502edf1d just after this paragraph. But here is what that commit replaced.
- /* check for N.N.N.N */
- sp = ident;
- if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
- sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
- sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
- sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '\0') return MCL_
- /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :) */
- return MCL_SUBNETWORK;
+
+ /*
+ * Treat unadorned IP addresses as MCL_SUBNETWORK.
+ * Everything else is MCL_FQDN.
+ */
+ ai = host_pton(ident);
+ if (ai != NULL) {
+ freeaddrinfo(ai);
+ return MCL_SUBNETWORK;
+ }
+
+ return MCL_FQDN;
}
The replaced logic also treats IP addresses as MCL_SUBNETWORK. That's from commit 54669c98 in 2005. Neil, do you remember why this semantic change was made?
On Oct 17, 2013, at 3:16 AM, Wangminlan <wangminlan@huawei.com> wrote:
> Hi,
> I went through the code of nfs-utils, check the function client_gettype in support/export/client.c:
> in nfs-utils-1-2-9-rc6, and in nfs-utils-1.2.6, they have this implementation in the final part:
> 770 /*
> 771 * Treat unadorned IP addresses as MCL_SUBNETWORK.
> 772 * Everything else is MCL_FQDN.
> 773 */
> 774 ai = host_pton(ident);
> 775 if (ai != NULL) {
> 776 freeaddrinfo(ai);
> 777 return MCL_SUBNETWORK;
> 778 }
> 779
> 780 return MCL_FQDN;
> 781 }
>
> while back in days of nfs-utils-1.0.7: client_gettype looks like this:
> 277 client_gettype(char *ident)
> 278 {
> 279 char *sp;
> 280
> 281 if (ident[0] == '\0')
> 282 return MCL_ANONYMOUS;
> 283 if (ident[0] == '@') {
> 284 #ifndef HAVE_INNETGR
> 285 xlog(L_WARNING, "netgroup support not compiled in");
> 286 #endif
> 287 return MCL_NETGROUP;
> 288 }
> 289 for (sp = ident; *sp; sp++) {
> 290 if (*sp == '*' || *sp == '?' || *sp == '[')
> 291 return MCL_WILDCARD;
> 292 if (*sp == '/')
> 293 return MCL_SUBNETWORK;
> 294 if (*sp == '\\' && sp[1])
> 295 sp++;
> 296 }
> 297 return MCL_FQDN;
> 298 }
>
> It's simple, and client like "192.168.0.21" is treated as MCL_FQDN.
> I tried the same operation in this version, there's no such problem as in nfs-utils-1.2.1 and nfs-utils-1.2.6.
>
>> -----Original Message-----
>> From: linux-nfs-owner@vger.kernel.org
>> [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Wangminlan
>> Sent: Wednesday, October 16, 2013 9:23 AM
>> To: J. Bruce Fields
>> Cc: linux-nfs@vger.kernel.org
>> Subject: RE: Different sequence of "exportfs" produce different effects on nfs
>> client mounts
>>
>> Hi, Bruce,
>> The nfs-utils on my box is nfs-utils-1.2.1-2.6.6, which is Suse distributed.
>> I tried the same experiment on fedora18, which use nfs-utils-1.2.6, and
>> got the same result.
>> I go through the code of support/export/client.c, found that in
>> client_get_type(), when the client is specified as an IP address(which can not
>> be resolved as an FQDN), it actually return the result: MCL_SUBNETWORK.
>> I guess that's the reason that the client "192.168.0.21" and
>> "192.168.0.0/16" both are sorted to the same category: MCL_SUBNETWORK,
>> so the order of exports matters here.
>> Is this what exportfs and mountd mean to be?
>> B.R
>> Minlan Wang
>>
>> On Tuesday, October 15, 2013 at 03:49AM +0000, Bruce Fields wrote:
>>> Looking at the mountd code....
>>>
>>> Looks like utils/mountd/cache.c makes no special effort to prioritize
>>> exports except in the v4root and crossmnt cases, neither an issue in
>>> your case.
>>>
>>> So yes it depends on ordering. From man exports:
>>>
>>> If a client matches more than one of the specifications above,
>>> then the first match from the above list order takes precedence
>>> - regardless of the order they appear on the export line.
>>> However, if a client matches more than one of the same type of
>>> specification (e.g. two netgroups), then the first match
>>> from the order they appear on the export line takes
>>> precedence.
>>>
>>> The order given is: single host, IP networks, wildcards, negroups,
>>> anonymous.
>>>
>>> So the single host exports should have taken precedence.
>>>
>>> The code here does look like it corectly implements the above ordering.
>>>
>>> What version of nfs-utils are you using?
>>>
>>> --b.
>>>
>>> On Tue, Oct 15, 2013 at 06:39:59AM +0000, Wangminlan wrote:
>>>> On Mon, Oct 14, 2013 at 16:46 +0000, Bruce Fields wrote:
>>>>> On Mon, Oct 14, 2013 at 02:16:58AM +0000, Wangminlan wrote:
>>>>>> Hi,
>>>>>> I’ve got a problem on the nfs exportfs command. I’m
>>> not
>>>>> sure if this is the right place to ask this, if not, can you please tell me
>>> where?
>>>>>>
>>>>>> Here’s what I need:
>>>>>> 1. I have a folder named /mnt/fs1 to be exported.
>>>>>> 2. All the host in subnetwork 192.168.0.0/16 should be able access
>>> this
>>>>> folder, but their root should be squashed.
>>>>>> 3. Some specified host in the same subnetwork can gain the root
>>>>> permission on the folder, for example: 192.168.0.21, 192.168.0.22.
>>>>>>
>>>>>> I’ve got a SLES11SP1 box as the nfs server, the nfs clients are
>>> SLES11SP1,
>>>>> too, and the protocol used between clients and server are NFSv3.
>>>>>> Here are the commands I used to do the export:
>>>>>> #exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1
>>>>>> #exportfs –o rw,no_root_squash 192.168.0.21:/mnt/fs1
>>>>>> #exportfs –o rw,no_root_squash 192.168.0.22:/mnt/fs1
>>>>>> After this, everything works as expected.
>>>> After this, the contents of /proc/net/rpc/auth.unix.ip/content and
>>> /proc/net/rpc/nfsd.export/content are:
>>>> NV200_01:/proc/net/rpc # cat auth.unix.ip/content
>>>> #class IP domain
>>>> nfsd 192.168.0.21 192.168.0.0/16,192.168.0.21
>>>> nfsd 0.0.0.0 -test-client-
>>>> # nfsd 100.43.189.1 -no-domain-
>>>>
>>>> NV200_01:/proc/net/rpc # cat nfsd.export/content
>>>> #path domain(flags)
>>>> /mnt/fs1
>>> -test-client-(rw,no_root_squash,sync,no_wdelay,fsid=0,anonuid=4294967
>>> 295,anongid=4294967295)
>>>> /mnt/fs1
>>> 192.168.0.0/16,192.168.0.21(rw,no_root_squash,sync,wdelay,no_subtree
>>> _check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
>>>> # /mnt/fs1
>>> 192.168.0.0/16,192.168.0.21(rw,no_root_squash,sync,wdelay,no_subtree
>>> _check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
>>>> Besides, the content of /var/lib/nfs/etab is:
>>>> NV200_01:/proc/net/rpc # cat /var/lib/nfs/etab
>>>> /mnt/fs1
>>> 192.168.0.22(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
>>>
>> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
>>> 4)
>>>> /mnt/fs1
>>> 192.168.0.21(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
>>>
>> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
>>> 4)
>>>> /mnt/fs1
>>> 192.168.0.0/16(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_
>>>
>> all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534
>>> )
>>>>>>
>>>>>> But, after the following operations:
>>>>>> #exportfs –u 192.168.0.0/16:/mnt/fs1 /* Delete
>>> this
>>>>> export */
>>>>>> # exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1
>>> /*
>>>>> And add it again */
>>>>>> Hosts on 192.168.0.21 and 192.168.0.22 doesn’t get root
>>> permission
>>>>> any more. when I tried to write a file, it complains about “Permission
>>> denied”.
>>>>>>
>>>>>> So, does the order of exportfs command has something to do the
>>> final
>>>>> result? Or am I doing something wrong?
>>>> After this, the contents of /proc/net/rpc/auth.unix.ip/content and
>>> /proc/net/rpc/nfsd.export/content are:
>>>> NV200_01:/proc/net/rpc # cat auth.unix.ip/content
>>>> #class IP domain
>>>> nfsd 192.168.0.21 192.168.0.0/16,192.168.0.21
>>>> nfsd 0.0.0.0 -test-client-
>>>> # nfsd 100.43.189.1 -no-domain-
>>>>
>>>> NV200_01:/proc/net/rpc # cat nfsd
>>>> nfsd nfsd.export/ nfsd.fh/
>>>> NV200_01:/proc/net/rpc # cat nfsd
>>>> nfsd nfsd.export/ nfsd.fh/
>>>> NV200_01:/proc/net/rpc # cat nfsd.export/content
>>>> #path domain(flags)
>>>> /mnt/fs1
>>> -test-client-(rw,no_root_squash,sync,no_wdelay,fsid=0,anonuid=4294967
>>> 295,anongid=4294967295)
>>>> /mnt/fs1
>>> 192.168.0.0/16,192.168.0.21(rw,root_squash,sync,wdelay,no_subtree_ch
>>> eck,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
>>>> And the content of /var/lib/nfs/etab is:
>>>> NV200_01:/proc/net/rpc # cat /var/lib/nfs/etab
>>>> /mnt/fs1
>>> 192.168.0.0/16(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_
>>>
>> all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534
>>> )
>>>> /mnt/fs1
>>> 192.168.0.22(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
>>>
>> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
>>> 4)
>>>> /mnt/fs1
>>> 192.168.0.21(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
>>>
>> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
>>> 4)
>>>>>
>>>>> That sounds like a bug. The contents of
>>>>> /proc/net/rpc/auth.unix.ip/content and
>> /proc/net/rpc/nfsd.export/content
>>>>> after getting the above "permission denied" might be interesting.
>> \x13��칻\x1c�&�~�&�\x18��+-��ݶ\x17��w��˛���m�b��g~ȧ�\x17��ܨ}���Ơz�&j:+v���
>>
> ����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[f
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-17 7:16 ` Wangminlan
2013-10-17 13:14 ` Chuck Lever
@ 2013-10-17 13:16 ` J. Bruce Fields
1 sibling, 0 replies; 13+ messages in thread
From: J. Bruce Fields @ 2013-10-17 13:16 UTC (permalink / raw)
To: Wangminlan; +Cc: linux-nfs, Neil Brown
On Thu, Oct 17, 2013 at 07:16:36AM +0000, Wangminlan wrote:
> Hi,
> I went through the code of nfs-utils, check the function client_gettype in support/export/client.c:
> in nfs-utils-1-2-9-rc6, and in nfs-utils-1.2.6, they have this implementation in the final part:
> 770 /*
> 771 * Treat unadorned IP addresses as MCL_SUBNETWORK.
> 772 * Everything else is MCL_FQDN.
> 773 */
> 774 ai = host_pton(ident);
> 775 if (ai != NULL) {
> 776 freeaddrinfo(ai);
> 777 return MCL_SUBNETWORK;
> 778 }
> 779
> 780 return MCL_FQDN;
> 781 }
>
> while back in days of nfs-utils-1.0.7: client_gettype looks like this:
> 277 client_gettype(char *ident)
> 278 {
> 279 char *sp;
> 280
> 281 if (ident[0] == '\0')
> 282 return MCL_ANONYMOUS;
> 283 if (ident[0] == '@') {
> 284 #ifndef HAVE_INNETGR
> 285 xlog(L_WARNING, "netgroup support not compiled in");
> 286 #endif
> 287 return MCL_NETGROUP;
> 288 }
> 289 for (sp = ident; *sp; sp++) {
> 290 if (*sp == '*' || *sp == '?' || *sp == '[')
> 291 return MCL_WILDCARD;
> 292 if (*sp == '/')
> 293 return MCL_SUBNETWORK;
> 294 if (*sp == '\\' && sp[1])
> 295 sp++;
> 296 }
> 297 return MCL_FQDN;
> 298 }
>
> It's simple, and client like "192.168.0.21" is treated as MCL_FQDN.
> I tried the same operation in this version, there's no such problem as in nfs-utils-1.2.1 and nfs-utils-1.2.6.
It looks like the change in behavior was intentional, see below.
Neil, do you remember what motivated that change?
I think Minlan Wang's right about what the behavior should be:
- it's what's still documented by "man exports".
- it seems least surprising.
- the ability to override networks with specific ip addresses is
useful. (Another alternative might be to classify them all as
MCL_SUBNETWORK and then always give smaller networks
priority.)
--b.
commit 54669c988cc7609a4aab1021604244424ebb795a
Author: neilbrown <neilbrown>
Date: Mon Mar 14 02:18:19 2005 +0000
treat N.N.N.N as a special case of MCL_SUBNETWORK instead of
MCL_FQDN
diff --git a/ChangeLog b/ChangeLog
index e2a38f2..d0985f8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
+2005-03-14 NeilBrown <neilb@cse.unsw.edu.au>
+ Denis Vlasenko <vda@ilport.com.ua>
+ * support/export/client.c(client_init and client_gettype):
+ treat N.N.N.N as a special case of MCL_SUBNETWORK instead of
+ MCL_FQDN
+
2005-03-06 G. Allen Morris III <gam3@gam3.net>
- * support/nfs/cacheio.c(readline): Could not real lines greater
+ * support/nfs/cacheio.c(readline): Could not read lines greater
than 128 bytes. [1157791]
* utils/exportfs/exports.man: Added a SEE ALSO section and
fixed 2 typos. [1018450]
diff --git a/support/export/client.c b/support/export/client.c
index 3884795..57176d8 100644
--- a/support/export/client.c
+++ b/support/export/client.c
@@ -138,7 +138,9 @@ client_init(nfs_client *clp, const char *hname, struct hostent *hp)
if (clp->m_type == MCL_SUBNETWORK) {
char *cp = strchr(clp->m_hostname, '/');
+ static char slash32[] = "/32";
+ if(!cp) cp = slash32;
*cp = '\0';
clp->m_addrlist[0].s_addr = inet_addr(clp->m_hostname);
if (strchr(cp + 1, '.')) {
@@ -443,5 +445,12 @@ client_gettype(char *ident)
if (*sp == '\\' && sp[1])
sp++;
}
- return MCL_FQDN;
+ /* check for N.N.N.N */
+ sp = ident;
+ if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
+ sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
+ sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
+ sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '\0') return MCL_FQDN;
+ /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :) */
+ return MCL_SUBNETWORK;
}
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-17 13:14 ` Chuck Lever
@ 2013-10-17 13:18 ` J. Bruce Fields
2013-10-17 21:32 ` NeilBrown
1 sibling, 0 replies; 13+ messages in thread
From: J. Bruce Fields @ 2013-10-17 13:18 UTC (permalink / raw)
To: Chuck Lever; +Cc: Wangminlan, Neil Brown, linux-nfs
On Thu, Oct 17, 2013 at 09:14:02AM -0400, Chuck Lever wrote:
> Hi-
>
> 281 if (ident[0] == '\0')
> 282 return MCL_ANONYMOUS;
> 283 if (ident[0] == '@') {
> 284 #ifndef HAVE_INNETGR
> 285 xlog(L_WARNING, "netgroup support not compiled in");
> 286 #endif
> 287 return MCL_NETGROUP;
> 288 }
> 289 for (sp = ident; *sp; sp++) {
> 290 if (*sp == '*' || *sp == '?' || *sp == '[')
> 291 return MCL_WILDCARD;
> 292 if (*sp == '/')
> 293 return MCL_SUBNETWORK;
> 294 if (*sp == '\\' && sp[1])
> 295 sp++;
> 296 }
>
> is still in play today. The "host_pton()" code you posted was added by commit 502edf1d just after this paragraph. But here is what that commit replaced.
>
> - /* check for N.N.N.N */
> - sp = ident;
> - if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
> - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
> - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
> - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '\0') return MCL_
> - /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :) */
> - return MCL_SUBNETWORK;
> +
> + /*
> + * Treat unadorned IP addresses as MCL_SUBNETWORK.
> + * Everything else is MCL_FQDN.
> + */
> + ai = host_pton(ident);
> + if (ai != NULL) {
> + freeaddrinfo(ai);
> + return MCL_SUBNETWORK;
> + }
> +
> + return MCL_FQDN;
> }
>
> The replaced logic also treats IP addresses as MCL_SUBNETWORK. That's from commit 54669c98 in 2005. Neil, do you remember why this semantic change was made?
Um, sorry Neil, looks like Chuck and I were both searching the git logs
at the same time!
--b.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-17 13:14 ` Chuck Lever
2013-10-17 13:18 ` J. Bruce Fields
@ 2013-10-17 21:32 ` NeilBrown
2013-10-20 22:49 ` NeilBrown
1 sibling, 1 reply; 13+ messages in thread
From: NeilBrown @ 2013-10-17 21:32 UTC (permalink / raw)
To: Chuck Lever; +Cc: Wangminlan, J. Bruce Fields, linux-nfs
[-- Attachment #1: Type: text/plain, Size: 12129 bytes --]
On Thu, 17 Oct 2013 09:14:02 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
> Hi-
>
> 281 if (ident[0] == '\0')
> 282 return MCL_ANONYMOUS;
> 283 if (ident[0] == '@') {
> 284 #ifndef HAVE_INNETGR
> 285 xlog(L_WARNING, "netgroup support not compiled in");
> 286 #endif
> 287 return MCL_NETGROUP;
> 288 }
> 289 for (sp = ident; *sp; sp++) {
> 290 if (*sp == '*' || *sp == '?' || *sp == '[')
> 291 return MCL_WILDCARD;
> 292 if (*sp == '/')
> 293 return MCL_SUBNETWORK;
> 294 if (*sp == '\\' && sp[1])
> 295 sp++;
> 296 }
>
> is still in play today. The "host_pton()" code you posted was added by commit 502edf1d just after this paragraph. But here is what that commit replaced.
>
> - /* check for N.N.N.N */
> - sp = ident;
> - if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
> - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
> - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
> - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '\0') return MCL_
> - /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :) */
> - return MCL_SUBNETWORK;
> +
> + /*
> + * Treat unadorned IP addresses as MCL_SUBNETWORK.
> + * Everything else is MCL_FQDN.
> + */
> + ai = host_pton(ident);
> + if (ai != NULL) {
> + freeaddrinfo(ai);
> + return MCL_SUBNETWORK;
> + }
> +
> + return MCL_FQDN;
> }
>
> The replaced logic also treats IP addresses as MCL_SUBNETWORK. That's from commit 54669c98 in 2005. Neil, do you remember why this semantic change was made?
>
See this thread:
http://marc.info/?t=110993941000003&r=1&w=2
It was a simple (though possibly flawed) solution to clearly differentiate
those addresses where DNS looked might be needed, and those where it was not.
I may have more to say later but I have to rush off now, so thought I'd just
post this anyway.
NeilBrown
>
>
> On Oct 17, 2013, at 3:16 AM, Wangminlan <wangminlan@huawei.com> wrote:
>
> > Hi,
> > I went through the code of nfs-utils, check the function client_gettype in support/export/client.c:
> > in nfs-utils-1-2-9-rc6, and in nfs-utils-1.2.6, they have this implementation in the final part:
> > 770 /*
> > 771 * Treat unadorned IP addresses as MCL_SUBNETWORK.
> > 772 * Everything else is MCL_FQDN.
> > 773 */
> > 774 ai = host_pton(ident);
> > 775 if (ai != NULL) {
> > 776 freeaddrinfo(ai);
> > 777 return MCL_SUBNETWORK;
> > 778 }
> > 779
> > 780 return MCL_FQDN;
> > 781 }
> >
> > while back in days of nfs-utils-1.0.7: client_gettype looks like this:
> > 277 client_gettype(char *ident)
> > 278 {
> > 279 char *sp;
> > 280
> > 281 if (ident[0] == '\0')
> > 282 return MCL_ANONYMOUS;
> > 283 if (ident[0] == '@') {
> > 284 #ifndef HAVE_INNETGR
> > 285 xlog(L_WARNING, "netgroup support not compiled in");
> > 286 #endif
> > 287 return MCL_NETGROUP;
> > 288 }
> > 289 for (sp = ident; *sp; sp++) {
> > 290 if (*sp == '*' || *sp == '?' || *sp == '[')
> > 291 return MCL_WILDCARD;
> > 292 if (*sp == '/')
> > 293 return MCL_SUBNETWORK;
> > 294 if (*sp == '\\' && sp[1])
> > 295 sp++;
> > 296 }
> > 297 return MCL_FQDN;
> > 298 }
> >
> > It's simple, and client like "192.168.0.21" is treated as MCL_FQDN.
> > I tried the same operation in this version, there's no such problem as in nfs-utils-1.2.1 and nfs-utils-1.2.6.
> >
> >> -----Original Message-----
> >> From: linux-nfs-owner@vger.kernel.org
> >> [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Wangminlan
> >> Sent: Wednesday, October 16, 2013 9:23 AM
> >> To: J. Bruce Fields
> >> Cc: linux-nfs@vger.kernel.org
> >> Subject: RE: Different sequence of "exportfs" produce different effects on nfs
> >> client mounts
> >>
> >> Hi, Bruce,
> >> The nfs-utils on my box is nfs-utils-1.2.1-2.6.6, which is Suse distributed.
> >> I tried the same experiment on fedora18, which use nfs-utils-1.2.6, and
> >> got the same result.
> >> I go through the code of support/export/client.c, found that in
> >> client_get_type(), when the client is specified as an IP address(which can not
> >> be resolved as an FQDN), it actually return the result: MCL_SUBNETWORK.
> >> I guess that's the reason that the client "192.168.0.21" and
> >> "192.168.0.0/16" both are sorted to the same category: MCL_SUBNETWORK,
> >> so the order of exports matters here.
> >> Is this what exportfs and mountd mean to be?
> >> B.R
> >> Minlan Wang
> >>
> >> On Tuesday, October 15, 2013 at 03:49AM +0000, Bruce Fields wrote:
> >>> Looking at the mountd code....
> >>>
> >>> Looks like utils/mountd/cache.c makes no special effort to prioritize
> >>> exports except in the v4root and crossmnt cases, neither an issue in
> >>> your case.
> >>>
> >>> So yes it depends on ordering. From man exports:
> >>>
> >>> If a client matches more than one of the specifications above,
> >>> then the first match from the above list order takes precedence
> >>> - regardless of the order they appear on the export line.
> >>> However, if a client matches more than one of the same type of
> >>> specification (e.g. two netgroups), then the first match
> >>> from the order they appear on the export line takes
> >>> precedence.
> >>>
> >>> The order given is: single host, IP networks, wildcards, negroups,
> >>> anonymous.
> >>>
> >>> So the single host exports should have taken precedence.
> >>>
> >>> The code here does look like it corectly implements the above ordering.
> >>>
> >>> What version of nfs-utils are you using?
> >>>
> >>> --b.
> >>>
> >>> On Tue, Oct 15, 2013 at 06:39:59AM +0000, Wangminlan wrote:
> >>>> On Mon, Oct 14, 2013 at 16:46 +0000, Bruce Fields wrote:
> >>>>> On Mon, Oct 14, 2013 at 02:16:58AM +0000, Wangminlan wrote:
> >>>>>> Hi,
> >>>>>> I’ve got a problem on the nfs exportfs command. I’m
> >>> not
> >>>>> sure if this is the right place to ask this, if not, can you please tell me
> >>> where?
> >>>>>>
> >>>>>> Here’s what I need:
> >>>>>> 1. I have a folder named /mnt/fs1 to be exported.
> >>>>>> 2. All the host in subnetwork 192.168.0.0/16 should be able access
> >>> this
> >>>>> folder, but their root should be squashed.
> >>>>>> 3. Some specified host in the same subnetwork can gain the root
> >>>>> permission on the folder, for example: 192.168.0.21, 192.168.0.22.
> >>>>>>
> >>>>>> I’ve got a SLES11SP1 box as the nfs server, the nfs clients are
> >>> SLES11SP1,
> >>>>> too, and the protocol used between clients and server are NFSv3.
> >>>>>> Here are the commands I used to do the export:
> >>>>>> #exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1
> >>>>>> #exportfs –o rw,no_root_squash 192.168.0.21:/mnt/fs1
> >>>>>> #exportfs –o rw,no_root_squash 192.168.0.22:/mnt/fs1
> >>>>>> After this, everything works as expected.
> >>>> After this, the contents of /proc/net/rpc/auth.unix.ip/content and
> >>> /proc/net/rpc/nfsd.export/content are:
> >>>> NV200_01:/proc/net/rpc # cat auth.unix.ip/content
> >>>> #class IP domain
> >>>> nfsd 192.168.0.21 192.168.0.0/16,192.168.0.21
> >>>> nfsd 0.0.0.0 -test-client-
> >>>> # nfsd 100.43.189.1 -no-domain-
> >>>>
> >>>> NV200_01:/proc/net/rpc # cat nfsd.export/content
> >>>> #path domain(flags)
> >>>> /mnt/fs1
> >>> -test-client-(rw,no_root_squash,sync,no_wdelay,fsid=0,anonuid=4294967
> >>> 295,anongid=4294967295)
> >>>> /mnt/fs1
> >>> 192.168.0.0/16,192.168.0.21(rw,no_root_squash,sync,wdelay,no_subtree
> >>> _check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> >>>> # /mnt/fs1
> >>> 192.168.0.0/16,192.168.0.21(rw,no_root_squash,sync,wdelay,no_subtree
> >>> _check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> >>>> Besides, the content of /var/lib/nfs/etab is:
> >>>> NV200_01:/proc/net/rpc # cat /var/lib/nfs/etab
> >>>> /mnt/fs1
> >>> 192.168.0.22(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
> >>>
> >> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
> >>> 4)
> >>>> /mnt/fs1
> >>> 192.168.0.21(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
> >>>
> >> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
> >>> 4)
> >>>> /mnt/fs1
> >>> 192.168.0.0/16(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_
> >>>
> >> all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534
> >>> )
> >>>>>>
> >>>>>> But, after the following operations:
> >>>>>> #exportfs –u 192.168.0.0/16:/mnt/fs1 /* Delete
> >>> this
> >>>>> export */
> >>>>>> # exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1
> >>> /*
> >>>>> And add it again */
> >>>>>> Hosts on 192.168.0.21 and 192.168.0.22 doesn’t get root
> >>> permission
> >>>>> any more. when I tried to write a file, it complains about “Permission
> >>> denied”.
> >>>>>>
> >>>>>> So, does the order of exportfs command has something to do the
> >>> final
> >>>>> result? Or am I doing something wrong?
> >>>> After this, the contents of /proc/net/rpc/auth.unix.ip/content and
> >>> /proc/net/rpc/nfsd.export/content are:
> >>>> NV200_01:/proc/net/rpc # cat auth.unix.ip/content
> >>>> #class IP domain
> >>>> nfsd 192.168.0.21 192.168.0.0/16,192.168.0.21
> >>>> nfsd 0.0.0.0 -test-client-
> >>>> # nfsd 100.43.189.1 -no-domain-
> >>>>
> >>>> NV200_01:/proc/net/rpc # cat nfsd
> >>>> nfsd nfsd.export/ nfsd.fh/
> >>>> NV200_01:/proc/net/rpc # cat nfsd
> >>>> nfsd nfsd.export/ nfsd.fh/
> >>>> NV200_01:/proc/net/rpc # cat nfsd.export/content
> >>>> #path domain(flags)
> >>>> /mnt/fs1
> >>> -test-client-(rw,no_root_squash,sync,no_wdelay,fsid=0,anonuid=4294967
> >>> 295,anongid=4294967295)
> >>>> /mnt/fs1
> >>> 192.168.0.0/16,192.168.0.21(rw,root_squash,sync,wdelay,no_subtree_ch
> >>> eck,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> >>>> And the content of /var/lib/nfs/etab is:
> >>>> NV200_01:/proc/net/rpc # cat /var/lib/nfs/etab
> >>>> /mnt/fs1
> >>> 192.168.0.0/16(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_
> >>>
> >> all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534
> >>> )
> >>>> /mnt/fs1
> >>> 192.168.0.22(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
> >>>
> >> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
> >>> 4)
> >>>> /mnt/fs1
> >>> 192.168.0.21(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
> >>>
> >> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
> >>> 4)
> >>>>>
> >>>>> That sounds like a bug. The contents of
> >>>>> /proc/net/rpc/auth.unix.ip/content and
> >> /proc/net/rpc/nfsd.export/content
> >>>>> after getting the above "permission denied" might be interesting.
> >> \x13��칻\x1c�&�~�&�\x18��+-��ݶ\x17��w��˛���m�b��g~ȧ�\x17��ܨ}���Ơz�&j:+v���
> >>
> > ����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[f
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-17 21:32 ` NeilBrown
@ 2013-10-20 22:49 ` NeilBrown
2013-10-21 9:47 ` Wangminlan
0 siblings, 1 reply; 13+ messages in thread
From: NeilBrown @ 2013-10-20 22:49 UTC (permalink / raw)
To: NeilBrown; +Cc: Chuck Lever, Wangminlan, J. Bruce Fields, linux-nfs
[-- Attachment #1: Type: text/plain, Size: 3510 bytes --]
On Fri, 18 Oct 2013 08:32:53 +1100 NeilBrown <neilb@suse.de> wrote:
> On Thu, 17 Oct 2013 09:14:02 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:
>
> > Hi-
> >
> > 281 if (ident[0] == '\0')
> > 282 return MCL_ANONYMOUS;
> > 283 if (ident[0] == '@') {
> > 284 #ifndef HAVE_INNETGR
> > 285 xlog(L_WARNING, "netgroup support not compiled in");
> > 286 #endif
> > 287 return MCL_NETGROUP;
> > 288 }
> > 289 for (sp = ident; *sp; sp++) {
> > 290 if (*sp == '*' || *sp == '?' || *sp == '[')
> > 291 return MCL_WILDCARD;
> > 292 if (*sp == '/')
> > 293 return MCL_SUBNETWORK;
> > 294 if (*sp == '\\' && sp[1])
> > 295 sp++;
> > 296 }
> >
> > is still in play today. The "host_pton()" code you posted was added by commit 502edf1d just after this paragraph. But here is what that commit replaced.
> >
> > - /* check for N.N.N.N */
> > - sp = ident;
> > - if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
> > - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
> > - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
> > - sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '\0') return MCL_
> > - /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :) */
> > - return MCL_SUBNETWORK;
> > +
> > + /*
> > + * Treat unadorned IP addresses as MCL_SUBNETWORK.
> > + * Everything else is MCL_FQDN.
> > + */
> > + ai = host_pton(ident);
> > + if (ai != NULL) {
> > + freeaddrinfo(ai);
> > + return MCL_SUBNETWORK;
> > + }
> > +
> > + return MCL_FQDN;
> > }
> >
> > The replaced logic also treats IP addresses as MCL_SUBNETWORK. That's from commit 54669c98 in 2005. Neil, do you remember why this semantic change was made?
> >
>
> See this thread:
>
> http://marc.info/?t=110993941000003&r=1&w=2
>
> It was a simple (though possibly flawed) solution to clearly differentiate
> those addresses where DNS looked might be needed, and those where it was not.
>
> I may have more to say later but I have to rush off now, so thought I'd just
> post this anyway.
>
Unfortunately I cannot see how that change ever made any important
difference, and the email exchanges ends without resolving anything.
It could only make a difference to the number of DNS lookups if there was
somewhere a test for whether clientlist[MCL_FQDN] was NULL, but there isn't
and never was.
So it seems very likely that:
diff --git a/support/export/client.c b/support/export/client.c
index ba2db8f..adbeed8 100644
--- a/support/export/client.c
+++ b/support/export/client.c
@@ -767,15 +767,5 @@ client_gettype(char *ident)
sp++;
}
- /*
- * Treat unadorned IP addresses as MCL_SUBNETWORK.
- * Everything else is MCL_FQDN.
- */
- ai = host_pton(ident);
- if (ai != NULL) {
- freeaddrinfo(ai);
- return MCL_SUBNETWORK;
- }
-
return MCL_FQDN;
}
is appropriate and may well fix the current issue.
It would be good to test how many DNS looks (hopefully none) are performed
when using a exports file that contains only IP addresses, both before and
after the patch.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply related [flat|nested] 13+ messages in thread
* RE: Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-20 22:49 ` NeilBrown
@ 2013-10-21 9:47 ` Wangminlan
0 siblings, 0 replies; 13+ messages in thread
From: Wangminlan @ 2013-10-21 9:47 UTC (permalink / raw)
To: NeilBrown; +Cc: Chuck Lever, J. Bruce Fields, linux-nfs
SSBhcHBsaWVkIHRoaXMgcGF0Y2ggdG8gbmZzLXV0aWxzLTEuMi42LCBpdCBmaXhlZCB0aGUgY3Vy
cmVudCBpc3N1ZS4NCg0KTXkgL2V0Yy9leHBvcnRzIGxvb2tzIGxpa2UgdGhpczoNCi9tZWRpYS9m
czEvICAgICAxMC4xNTguMC4wLzE2KHJ3LHJvb3Rfc3F1YXNoLG5vX3N1YnRyZWVfY2hlY2spDQov
bWVkaWEvZnMxLyAgICAgMTAuMTU4LjE5Mi43MShydyxub19yb290X3NxdWFzaCxub19zdWJ0cmVl
X2NoZWNrKQ0KL21lZGlhL2ZzMS8gICAgIDEwLjE1OC4xOTIuNzIocncsbm9fcm9vdF9zcXVhc2gs
bm9fc3VidHJlZV9jaGVjaykNCi9tZWRpYS9mczEvICAgICAxMC4xNTguMTkyLjczKHJ3LG5vX3Jv
b3Rfc3F1YXNoLG5vX3N1YnRyZWVfY2hlY2spDQovbWVkaWEvZnMxLyAgICAgMTAuMTU4LjE5Mi43
NChydyxub19yb290X3NxdWFzaCxub19zdWJ0cmVlX2NoZWNrKQ0KDQpBbmQgSSBhbHNvIGNhcHR1
cmVkIGRucyBsb29rdXAgdHJhZmZpYyBieSBjb21tYW5kICJ0Y3BkdW1wIC1pIGV0aDAgLXZ2diBo
b3N0IGRuc19zZXJ2ZXIiIGR1cmluZyB0aGUgZm9sbG93aW5nIHByb2NlZHVyZToNCiNleHBvcnRm
cyAtdWENCiNleHBvcnRmcyAtYQ0Kb24gdGhlIHNlcnZlciwgYW5kIHRoZSBuZnMgbW91bnQgcHJv
Y2VkdXJlIG9uIHRoZSBjbGllbnQuDQpUaGVyZSdzIG5vbmUgZG5zIGxvb2t1cCByZWxhdGVkIHRy
YWZmaWMsIG5laXRoZXIgYmVmb3JlIHRoZSBwYXRjaCwgbm9yIGFmdGVyIGl0Lg0KDQpUaGFua3Mg
dG8gYWxsIG9mIHlvdSwgZm9yIGhlbHBpbmcgbWUgZml4IHRoaXMgaXNzdWUsIGFuZCB0aGUgdGlt
ZSB5b3Ugc3BlbnQgb24gcmV2aWV3aW5nIHRoZSBjb2RlLg0KDQpCLlIuDQpNaW5sYW4gV2FuZw0K
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5laWxCcm93biBbbWFpbHRv
Om5laWxiQHN1c2UuZGVdDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMSwgMjAxMyA2OjQ5IEFN
DQo+IFRvOiBOZWlsQnJvd24NCj4gQ2M6IENodWNrIExldmVyOyBXYW5nbWlubGFuOyBKLiBCcnVj
ZSBGaWVsZHM7IGxpbnV4LW5mc0B2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IERpZmZl
cmVudCBzZXF1ZW5jZSBvZiAiZXhwb3J0ZnMiIHByb2R1Y2UgZGlmZmVyZW50IGVmZmVjdHMgb24g
bmZzDQo+IGNsaWVudCBtb3VudHMNCj4gDQo+IA0KPiBVbmZvcnR1bmF0ZWx5IEkgY2Fubm90IHNl
ZSBob3cgdGhhdCBjaGFuZ2UgZXZlciBtYWRlIGFueSBpbXBvcnRhbnQNCj4gZGlmZmVyZW5jZSwg
YW5kIHRoZSBlbWFpbCBleGNoYW5nZXMgZW5kcyB3aXRob3V0IHJlc29sdmluZyBhbnl0aGluZy4N
Cj4gDQo+IEl0IGNvdWxkIG9ubHkgbWFrZSBhIGRpZmZlcmVuY2UgdG8gdGhlIG51bWJlciBvZiBE
TlMgbG9va3VwcyBpZiB0aGVyZSB3YXMNCj4gc29tZXdoZXJlIGEgdGVzdCBmb3Igd2hldGhlciBj
bGllbnRsaXN0W01DTF9GUUROXSB3YXMgTlVMTCwgYnV0IHRoZXJlIGlzbid0DQo+IGFuZCBuZXZl
ciB3YXMuDQo+IA0KPiBTbyBpdCBzZWVtcyB2ZXJ5IGxpa2VseSB0aGF0Og0KPiANCj4gZGlmZiAt
LWdpdCBhL3N1cHBvcnQvZXhwb3J0L2NsaWVudC5jIGIvc3VwcG9ydC9leHBvcnQvY2xpZW50LmMg
aW5kZXgNCj4gYmEyZGI4Zi4uYWRiZWVkOCAxMDA2NDQNCj4gLS0tIGEvc3VwcG9ydC9leHBvcnQv
Y2xpZW50LmMNCj4gKysrIGIvc3VwcG9ydC9leHBvcnQvY2xpZW50LmMNCj4gQEAgLTc2NywxNSAr
NzY3LDUgQEAgY2xpZW50X2dldHR5cGUoY2hhciAqaWRlbnQpDQo+ICAJCQlzcCsrOw0KPiAgCX0N
Cj4gDQo+IC0JLyoNCj4gLQkgKiBUcmVhdCB1bmFkb3JuZWQgSVAgYWRkcmVzc2VzIGFzIE1DTF9T
VUJORVRXT1JLLg0KPiAtCSAqIEV2ZXJ5dGhpbmcgZWxzZSBpcyBNQ0xfRlFETi4NCj4gLQkgKi8N
Cj4gLQlhaSA9IGhvc3RfcHRvbihpZGVudCk7DQo+IC0JaWYgKGFpICE9IE5VTEwpIHsNCj4gLQkJ
ZnJlZWFkZHJpbmZvKGFpKTsNCj4gLQkJcmV0dXJuIE1DTF9TVUJORVRXT1JLOw0KPiAtCX0NCj4g
LQ0KPiAgCXJldHVybiBNQ0xfRlFETjsNCj4gIH0NCj4gDQo+IGlzIGFwcHJvcHJpYXRlIGFuZCBt
YXkgd2VsbCBmaXggdGhlIGN1cnJlbnQgaXNzdWUuDQo+IA0KPiBJdCB3b3VsZCBiZSBnb29kIHRv
IHRlc3QgaG93IG1hbnkgRE5TIGxvb2tzIChob3BlZnVsbHkgbm9uZSkgYXJlIHBlcmZvcm1lZA0K
PiB3aGVuIHVzaW5nIGEgZXhwb3J0cyBmaWxlIHRoYXQgY29udGFpbnMgb25seSBJUCBhZGRyZXNz
ZXMsIGJvdGggYmVmb3JlIGFuZCBhZnRlcg0KPiB0aGUgcGF0Y2guDQo+IA0KPiBOZWlsQnJvd24N
Cg==
^ permalink raw reply [flat|nested] 13+ messages in thread
* Different sequence of "exportfs" produce different effects on nfs client mounts
2013-10-11 20:15 [PATCH] nfs: Remove useless 'error' assignment Geyslan G. Bem
@ 2013-10-14 1:20 ` Wangminlan
0 siblings, 0 replies; 13+ messages in thread
From: Wangminlan @ 2013-10-14 1:20 UTC (permalink / raw)
To: linux-nfs; +Cc: Wangminlan
Hi,
I've got a problem on the nfs export operation. I'm not sure if this is the right place to ask this, if not, can you please tell me where?
Here's what I need:
1. I have a folder named /mnt/fs1 to be exported.
2. All the host in subnetwork 192.168.0.0/16 should be able access this folder, but their root should be squashed.
3. Some specified host in the same subnetwork can gain the root permission on the folder, for example: 192.168.0.21, 192.168.0.22.
I've got a SLES11SP1 box as the nfs server, the nfs clients are SLES11SP1, too. And the test uses nfsv3.
Here are the commands I used to do the export:
#exportfs -o rw,root_squash 192.168.0.0/16:/mnt/fs1 #exportfs -o rw,no_root_squash 192.168.0.21:/mnt/fs1 #exportfs -o rw,no_root_squash 192.168.0.22:/mnt/fs1
After this, everything works as expected.
But, after the following operations:
#exportfs -u 192.168.0.0/16:/mnt/fs1 /* Delete this export */
# exportfs -o rw,root_squash 192.168.0.0/16:/mnt/fs1 /* And add it again */
Hosts on 192.168.0.21 and 192.168.0.22 doesn't get root permission any more. when I tried to write a file, it complains about "Permission denied".
So, does the order of exportfs command has something to do the final result? Or am I doing something wrong?
B.R
Minlan Wang
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-10-21 9:50 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-14 2:16 Different sequence of "exportfs" produce different effects on nfs client mounts Wangminlan
2013-10-14 17:45 ` J. Bruce Fields
2013-10-15 6:39 ` Wangminlan
2013-10-15 15:49 ` J. Bruce Fields
2013-10-16 1:22 ` Wangminlan
2013-10-17 7:16 ` Wangminlan
2013-10-17 13:14 ` Chuck Lever
2013-10-17 13:18 ` J. Bruce Fields
2013-10-17 21:32 ` NeilBrown
2013-10-20 22:49 ` NeilBrown
2013-10-21 9:47 ` Wangminlan
2013-10-17 13:16 ` J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2013-10-11 20:15 [PATCH] nfs: Remove useless 'error' assignment Geyslan G. Bem
2013-10-14 1:20 ` Different sequence of "exportfs" produce different effects on nfs client mounts Wangminlan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.