* 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@vger.kernel.org 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@vger.kernel.org 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@vger.kernel.org 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@vger.kernel.org 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@vger.kernel.org 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@vger.kernel.org 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@vger.kernel.org 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 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@vger.kernel.org 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@vger.kernel.org [-- 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@vger.kernel.org [-- 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@vger.kernel.org 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
* 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@vger.kernel.org, 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
* [PATCH] nfs: Remove useless 'error' assignment @ 2013-10-11 20:15 Geyslan G. Bem 2013-10-14 1:20 ` Different sequence of "exportfs" produce different effects on nfs client mounts Wangminlan 0 siblings, 1 reply; 13+ messages in thread From: Geyslan G. Bem @ 2013-10-11 20:15 UTC (permalink / raw) To: Trond.Myklebust; +Cc: linux-nfs, linux-kernel, joe, kernel-br, Geyslan G. Bem the 'error' variable was been assigned twice in vain. Signed-off-by: Geyslan G. Bem <geyslan@gmail.com> --- fs/nfs/unlink.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c index bb939ed..0c29b1b 100644 --- a/fs/nfs/unlink.c +++ b/fs/nfs/unlink.c @@ -493,7 +493,7 @@ nfs_sillyrename(struct inode *dir, struct dentry *dentry) unsigned long long fileid; struct dentry *sdentry; struct rpc_task *task; - int error = -EIO; + int error = -EBUSY; dfprintk(VFS, "NFS: silly-rename(%s/%s, ct=%d)\n", dentry->d_parent->d_name.name, dentry->d_name.name, @@ -503,7 +503,6 @@ nfs_sillyrename(struct inode *dir, struct dentry *dentry) /* * We don't allow a dentry to be silly-renamed twice. */ - error = -EBUSY; if (dentry->d_flags & DCACHE_NFSFS_RENAMED) goto out; -- 1.8.4 ^ permalink raw reply related [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@vger.kernel.org; +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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).