Hi
Is it possible for nfs4 to respect the acls I have setup on an ext4 export?
Thanks,
Steve
openSUSE 12.1
On 02/23/2012 12:39 PM, Jeff Layton wrote:
> On Thu, 23 Feb 2012 08:15:26 +0100
> steve<[email protected]> wrote:
>
>> Hi everyone
>> I'm sorry to bump this but I've tried the opensuse, ubuntu and samba
>> lists without any luck.
>>
>> The acls I have created are not inherited when exporting via nfs4. Can
>> anyone help me with this? Tell me it can/can't be done? Versions of nfs
>> to use? Details below.
>> Thanks,
>> Steve
>>
>>
> The NFSv4 protocol does not support POSIX ACLs. It has its own
> implementation of ACLs that is much more windows-like (yet not exactly
> either).
>
> For enforcement, it doesn't really matter too much -- the server
> enforces POSIX ACLs since that's done within the VFS and local
> filesystem. The only "problem" is that you can't see and manipulate
> ACLs directly over NFSv4 using standard POSIX acl tools.
>
> You can view and manipulate NFSv4 ACLs using the programs in the
> nfs4-acl-tools package. Linux' nfsd will map those to/from POSIX ACLs
> but it's always going to be a lossy mapping.
>
> There are also patches in progress to add the ability for Linux
> filesystems to support NFSv4/Windows ACLs natively. That effort is
> called RichACLs, but it's not in mainline yet, and development on it
> seems to have stalled of late.
>
Hi Jeff
Thanks for the reply. I'm trying to make the files created in a share
take on group rw.
The trouble is that I've already tried setting the acl's via
nfs4_setfacl on the mounted share too (please see details below). The
acl + appears on the unmounted share and behaves as expected even when
it is not mounted. The mounted share however ignores the acl I've set.
I've tried remounting but still no acl is effective.
My workaround is to scan the folder and change the files to group rw
every few seconds.
What am I missing here?
Thanks again,
Steve
>> On 02/19/2012 06:15 PM, steve wrote:
>>> On 18/02/12 21:08, steve wrote:
>>>> Hi
>>>> Is it possible for nfs4 to respect the acls I have setup on an ext4
>>>> export?
>>>> Thanks,
>>>> Steve
>>>>
>>>> openSUSE 12.1
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Sorry, this is what I've tried so far:
>>> cat /etc/exports
>>> /home
>>> *(rw,no_root_squash,sec=none:sys:krb5:krb5i:krb5p,no_subtree_check,insecure)
>>>
>>> 1. Make a folder to share:
>>> hh3:/home/CACTUS # mkdir -m 770 dropbox
>>> hh3:/home/CACTUS # chown root:suseusers dropbox
>>>
>>> 2. Mount the share:
>>> hh3:/home/CACTUS # mount -t nfs4 hh3:/home /mnt
>>>
>>> 3. Look at the acls:
>>> nfs4_getfacl /mnt/CACTUS/dropbox
>>> A::OWNER@:rwaDxtTcCy
>>> A::GROUP@:rwaDxtcy
>>> A::EVERYONE@:tcy
>>>
>>> Set an acl so that members of suseusers have rw on the share:
>>> hh3:/home/CACTUS # nfs4_setfacl -a A:g:[email protected]:RW
>>> /mnt/CACTUS/dropbox
>>>
>>> hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
>>> A::OWNER@:rwaDxtTcCy
>>> A::GROUP@:rwaDxtcy
>>> A:g:[email protected]:rwaDtcy
>>> A::EVERYONE@:tcy
>>>
>>> 4. Yes. Back in the unmounted directory, the acl + has appeared:
>>> hh3:/home/CACTUS # ls -la dropbox/
>>> total 8
>>> drwxrwx---+ 2 root suseusers 4096 Feb 19 10:55 .
>>> drwxr-xr-x 9 root root 4096 Feb 19 10:55 ..
>>>
>>> 5. On the mounted share, the acl is not visible. steve6 can create a
>>> file but it is _not_ group rw:
>>> steve6@hh3:~> cd /mnt/CACTUS/dropbox/
>>> steve6@hh3:/mnt/CACTUS/dropbox> touch hola.txt
>>> steve6@hh3:/mnt/CACTUS/dropbox> ls -la
>>> total 8
>>> drwxrwx--- 2 root suseusers 4096 Feb 19 11:02 .
>>> drwxr-xr-x 9 root root 4096 Feb 19 10:55 ..
>>> -rw-r--r-- 1 steve6 suseusers 0 Feb 19 11:02 hola.txt
>>>
>>> 6. Recreate the share but this time with a posix acl:
>>> setfacl -d -m g::rw /home/CACTUS/dropbox
>>> steve6@hh3:/home/CACTUS> touch dropbox/h
>>> steve6@hh3:/home/CACTUS> ls -la dropbox/
>>> total 8
>>> drwxrws---+ 2 root suseusers 4096 Feb 19 11:13 .
>>> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
>>> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
>>>
>>> Yes. Now when steve6 creates a file it _is_ group rw. = posix acl is
>>> working.
>>>
>>> 7. Mount the new posix share and test again:
>>> hh3:/home/CACTUS #chmod g+s /home/CACTUS/dropbox
>>> hh3:/home/CACTUS # mount -t nfs4 hh3:/home /mnt
>>> hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
>>> A::OWNER@:rwaDxtTcCy
>>> A::GROUP@:rwaDxtcy
>>> A::EVERYONE@:tcy
>>> A:fdi:OWNER@:rwaDxtTcCy
>>> A:fdi:GROUP@:rwaDtcy
>>> A:fdi:EVERYONE@:tcy
>>>
>>> steve6@hh3:/mnt/CACTUS/dropbox> touch h2
>>> steve6@hh3:/mnt/CACTUS/dropbox> ls -la
>>> total 8
>>> drwxrws--- 2 root suseusers 4096 Feb 19 11:19 .
>>> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
>>> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
>>> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:19 h2
>>> hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
>>> A::OWNER@:rwaDxtTcCy
>>> A::GROUP@:rwaDxtcy
>>> A::EVERYONE@:tcy
>>> A:fdi:OWNER@:rwaDxtTcCy
>>> A:fdi:GROUP@:rwaDtcy
>>> A:fdi:EVERYONE@:tcy
>>> hh3:/home/CACTUS # nfs4_setfacl -a A:fdi:GROUP@:RWX
>>> /mnt/CACTUS/dropboxhh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
>>> A::OWNER@:rwaDxtTcCy
>>> A::GROUP@:rwaDxtcy
>>> A::EVERYONE@:tcy
>>> A:fdi:OWNER@:rwaDxtTcCy
>>> A:fdi:GROUP@:rwaDxtcy
>>> A:fdi:EVERYONE@:tcy
>>>
>>> steve6@hh3:/mnt/CACTUS/dropbox> touch h3
>>> steve6@hh3:/mnt/CACTUS/dropbox> ls -la
>>> total 8
>>> drwxrws--- 2 root suseusers 4096 Feb 19 11:21 .
>>> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
>>> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
>>> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:19 h2
>>> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:21 h3
>>>
>>> Still no group rw on created files. = nfs4 acl is not working as
>>> expected.
>>>
>>> Workaround. Get the out the big hammer:
>>> #!/bin/sh
>>> while true; do $(chmod -R g+w /home/CACTUS/dropbox); sleep 2; done
>>>
>>> Question:
>>> What am I missing? How do I set files created on an nfs4 share to take
>>> group rw?
>>>
>>> Thanks,
>>> Steve
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Sat, Feb 25, 2012 at 09:19:37AM +0100, steve wrote:
> On 23/02/12 17:08, steve wrote:
> >On 02/23/2012 04:42 PM, J. Bruce Fields wrote:
> >>>>First, if you want an ace on a directory to be inherited by files and
> >>>>directories created under that directory, make sure you're setting
> >>>>the f
> >>>>and d flags (see nfs4_getfacl -H).
> >>>>
> >>>>Second, there's a umask problem: posix acl inheritance overrides the
> >>>>umask, but nfs4 acl inheritance isn't doing that. (The client combines
> >>>>the create mode and the umask and sets both together, there's no way
> >>>>for
> >>>>the server to even tell what the umask is.)
> >>>>
> >>>>(We should do something about this if we can: maybe modifying the
> >>>>client
> >>>>to scan the directory acl for any inheritable aces and leaving out the
> >>>>umask if they're found? It has the obvious race, but I seem to recall
> >>>>we live with that in the v3 case. Or maybe there's something more
> >>>>clever, but this comes up every now and then and I can't remember a
> >>>>better solution.)
> >>>>
>
> Hi everyone
>
> This really is a show stopper for us.
>
> Would it be possible to give users the choice of being able to
> disable nfs4 acls so we can fall back to POSIX or nt acls? Or at
> least until the nfs4 team have had time to consider the situation?
The NFSv4 protocol has no support for posix acls, so this isn't an
option; possibly you're best off with v3 for some reason. (Why the
migration to v4?)
--b.
>
> Mounting with -o nofacl in the hope that the POSIX acl set on the
> unmounted directory would take effect, seems to have no effect.
>
> What I'm doing at the moment is scanning the unmounted directory
> every few seconds using 'find' and changing the files to g+rw:-(
>
> Thanks,
> Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1uZnMtb3duZXJAdmdl
ci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtbmZzLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24g
QmVoYWxmIE9mIHN0ZXZlDQo+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMywgMjAxMiAzOjE1
IFBNDQo+IFRvOiBsaW51eC1uZnNAdmdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBQT1NJ
WCBhY2xzIG92ZXIgbmZzNA0KPiANCj4gSGkgZXZlcnlvbmUNCj4gSSdtIHNvcnJ5IHRvIGJ1bXAg
dGhpcyBidXQgSSd2ZSB0cmllZCB0aGUgb3BlbnN1c2UsIHVidW50dSBhbmQgc2FtYmENCj4gbGlz
dHMgd2l0aG91dCBhbnkgbHVjay4NCk5vdCByZWFkaW5nIHRoZSBkZXRhaWxzIGluIHlvdXIgc2V0
dXAsIGJ1dCBtYXliZSBmb2xsb3dpbmcgc3VtbWFyeSBjYW4gaGVscCB5b3UgYSBiaXQuDQpodHRw
Oi8vd3d3LnN1c2UuZGUvfmFncnVlbi9hY2wvbGludXgtYWNscy9vbmxpbmUvDQoNCkNoZWVycywN
ClRhbw0KPiANCj4gVGhlIGFjbHMgSSBoYXZlIGNyZWF0ZWQgYXJlIG5vdCBpbmhlcml0ZWQgd2hl
biBleHBvcnRpbmcgdmlhIG5mczQuIENhbg0KPiBhbnlvbmUgaGVscCBtZSB3aXRoIHRoaXM/IFRl
bGwgbWUgaXQgY2FuL2Nhbid0IGJlIGRvbmU/IFZlcnNpb25zIG9mIG5mcw0KPiB0byB1c2U/IERl
dGFpbHMgYmVsb3cuDQo+IFRoYW5rcywNCj4gU3RldmUNCj4gDQo+IA0KPiBPbiAwMi8xOS8yMDEy
IDA2OjE1IFBNLCBzdGV2ZSB3cm90ZToNCj4gPiBPbiAxOC8wMi8xMiAyMTowOCwgc3RldmUgd3Jv
dGU6DQo+ID4+IEhpDQo+ID4+IElzIGl0IHBvc3NpYmxlIGZvciBuZnM0IHRvIHJlc3BlY3QgdGhl
IGFjbHMgSSBoYXZlIHNldHVwIG9uIGFuIGV4dDQNCj4gPj4gZXhwb3J0Pw0KPiA+PiBUaGFua3Ms
DQo+ID4+IFN0ZXZlDQo+ID4+DQo+ID4+IG9wZW5TVVNFIDEyLjENCj4gPj4gLS0NCj4gPj4gVG8g
dW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxp
bnV4LW5mcyIgaW4NCj4gPj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2Vy
Lmtlcm5lbC5vcmcNCj4gPj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0cDovL3ZnZXIua2Vy
bmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo+ID4gU29ycnksIHRoaXMgaXMgd2hhdCBJJ3Zl
IHRyaWVkIHNvIGZhcjoNCj4gPiAgY2F0IC9ldGMvZXhwb3J0cw0KPiA+IC9ob21lDQo+ID4gKihy
dyxub19yb290X3NxdWFzaCxzZWM9bm9uZTpzeXM6a3JiNTprcmI1aTprcmI1cCxub19zdWJ0cmVl
X2NoZWNrLGluc2VjdXJlKQ0KPiA+DQo+ID4gMS4gTWFrZSBhIGZvbGRlciB0byBzaGFyZToNCj4g
PiBoaDM6L2hvbWUvQ0FDVFVTICMgbWtkaXIgLW0gNzcwIGRyb3Bib3gNCj4gPiBoaDM6L2hvbWUv
Q0FDVFVTICMgY2hvd24gcm9vdDpzdXNldXNlcnMgZHJvcGJveA0KPiA+DQo+ID4gMi4gTW91bnQg
dGhlIHNoYXJlOg0KPiA+IGhoMzovaG9tZS9DQUNUVVMgIyBtb3VudCAtdCBuZnM0IGhoMzovaG9t
ZSAvbW50DQo+ID4NCj4gPiAzLiBMb29rIGF0IHRoZSBhY2xzOg0KPiA+IG5mczRfZ2V0ZmFjbCAv
bW50L0NBQ1RVUy9kcm9wYm94DQo+ID4gQTo6T1dORVJAOnJ3YUR4dFRjQ3kNCj4gPiBBOjpHUk9V
UEA6cndhRHh0Y3kNCj4gPiBBOjpFVkVSWU9ORUA6dGN5DQo+ID4NCj4gPiBTZXQgYW4gYWNsIHNv
IHRoYXQgbWVtYmVycyBvZiBzdXNldXNlcnMgaGF2ZSBydyBvbiB0aGUgc2hhcmU6DQo+ID4gaGgz
Oi9ob21lL0NBQ1RVUyAjIG5mczRfc2V0ZmFjbCAtYSBBOmc6c3VzZXVzZXJzQGhoMy5zaXRlOlJX
DQo+ID4gL21udC9DQUNUVVMvZHJvcGJveA0KPiA+DQo+ID4gaGgzOi9ob21lL0NBQ1RVUyAjIG5m
czRfZ2V0ZmFjbCAvbW50L0NBQ1RVUy9kcm9wYm94Lw0KPiA+IEE6Ok9XTkVSQDpyd2FEeHRUY0N5
DQo+ID4gQTo6R1JPVVBAOnJ3YUR4dGN5DQo+ID4gQTpnOnN1c2V1c2Vyc0BoaDMuc2l0ZTpyd2FE
dGN5DQo+ID4gQTo6RVZFUllPTkVAOnRjeQ0KPiA+DQo+ID4gNC4gWWVzLiBCYWNrIGluIHRoZSB1
bm1vdW50ZWQgZGlyZWN0b3J5LCB0aGUgYWNsICsgaGFzIGFwcGVhcmVkOg0KPiA+IGhoMzovaG9t
ZS9DQUNUVVMgIyBscyAtbGEgZHJvcGJveC8NCj4gPiB0b3RhbCA4DQo+ID4gZHJ3eHJ3eC0tLSsg
MiByb290IHN1c2V1c2VycyA0MDk2IEZlYiAxOSAxMDo1NSAuDQo+ID4gZHJ3eHIteHIteCAgOSBy
b290IHJvb3QgICAgICA0MDk2IEZlYiAxOSAxMDo1NSAuLg0KPiA+DQo+ID4gNS4gT24gdGhlIG1v
dW50ZWQgc2hhcmUsIHRoZSBhY2wgaXMgbm90IHZpc2libGUuIHN0ZXZlNiBjYW4gY3JlYXRlIGEN
Cj4gPiBmaWxlIGJ1dCBpdCBpcyBfbm90XyBncm91cCBydzoNCj4gPiBzdGV2ZTZAaGgzOn4+IGNk
IC9tbnQvQ0FDVFVTL2Ryb3Bib3gvDQo+ID4gc3RldmU2QGhoMzovbW50L0NBQ1RVUy9kcm9wYm94
PiB0b3VjaCBob2xhLnR4dA0KPiA+IHN0ZXZlNkBoaDM6L21udC9DQUNUVVMvZHJvcGJveD4gbHMg
LWxhDQo+ID4gdG90YWwgOA0KPiA+IGRyd3hyd3gtLS0gMiByb290ICAgc3VzZXVzZXJzIDQwOTYg
RmViIDE5IDExOjAyIC4NCj4gPiBkcnd4ci14ci14IDkgcm9vdCAgIHJvb3QgICAgICA0MDk2IEZl
YiAxOSAxMDo1NSAuLg0KPiA+IC1ydy1yLS1yLS0gMSBzdGV2ZTYgc3VzZXVzZXJzICAgIDAgRmVi
IDE5IDExOjAyIGhvbGEudHh0DQo+ID4NCj4gPiA2LiBSZWNyZWF0ZSB0aGUgc2hhcmUgYnV0IHRo
aXMgdGltZSB3aXRoIGEgcG9zaXggYWNsOg0KPiA+IHNldGZhY2wgLWQgLW0gZzo6cncgL2hvbWUv
Q0FDVFVTL2Ryb3Bib3gNCj4gPiBzdGV2ZTZAaGgzOi9ob21lL0NBQ1RVUz4gdG91Y2ggZHJvcGJv
eC9oDQo+ID4gc3RldmU2QGhoMzovaG9tZS9DQUNUVVM+IGxzIC1sYSBkcm9wYm94Lw0KPiA+IHRv
dGFsIDgNCj4gPiBkcnd4cndzLS0tKyAyIHJvb3QgICBzdXNldXNlcnMgNDA5NiBGZWIgMTkgMTE6
MTMgLg0KPiA+IGRyd3hyLXhyLXggIDkgcm9vdCAgIHJvb3QgICAgICA0MDk2IEZlYiAxOSAxMTox
MSAuLg0KPiA+IC1ydy1ydy0tLS0gIDEgc3RldmU2IHN1c2V1c2VycyAgICAwIEZlYiAxOSAxMTox
MyBoDQo+ID4NCj4gPiBZZXMuIE5vdyB3aGVuIHN0ZXZlNiBjcmVhdGVzIGEgZmlsZSBpdCBfaXNf
IGdyb3VwIHJ3LiA9IHBvc2l4IGFjbCBpcw0KPiA+IHdvcmtpbmcuDQo+ID4NCj4gPiA3LiBNb3Vu
dCB0aGUgbmV3IHBvc2l4IHNoYXJlIGFuZCB0ZXN0IGFnYWluOg0KPiA+IGhoMzovaG9tZS9DQUNU
VVMgI2NobW9kIGcrcyAvaG9tZS9DQUNUVVMvZHJvcGJveA0KPiA+IGhoMzovaG9tZS9DQUNUVVMg
IyBtb3VudCAtdCBuZnM0IGhoMzovaG9tZSAvbW50DQo+ID4gaGgzOi9ob21lL0NBQ1RVUyAjIG5m
czRfZ2V0ZmFjbCAvbW50L0NBQ1RVUy9kcm9wYm94Lw0KPiA+IEE6Ok9XTkVSQDpyd2FEeHRUY0N5
DQo+ID4gQTo6R1JPVVBAOnJ3YUR4dGN5DQo+ID4gQTo6RVZFUllPTkVAOnRjeQ0KPiA+IEE6ZmRp
Ok9XTkVSQDpyd2FEeHRUY0N5DQo+ID4gQTpmZGk6R1JPVVBAOnJ3YUR0Y3kNCj4gPiBBOmZkaTpF
VkVSWU9ORUA6dGN5DQo+ID4NCj4gPiBzdGV2ZTZAaGgzOi9tbnQvQ0FDVFVTL2Ryb3Bib3g+IHRv
dWNoIGgyDQo+ID4gc3RldmU2QGhoMzovbW50L0NBQ1RVUy9kcm9wYm94PiBscyAtbGENCj4gPiB0
b3RhbCA4DQo+ID4gZHJ3eHJ3cy0tLSAyIHJvb3QgICBzdXNldXNlcnMgNDA5NiBGZWIgMTkgMTE6
MTkgLg0KPiA+IGRyd3hyLXhyLXggOSByb290ICAgcm9vdCAgICAgIDQwOTYgRmViIDE5IDExOjEx
IC4uDQo+ID4gLXJ3LXJ3LS0tLSAxIHN0ZXZlNiBzdXNldXNlcnMgICAgMCBGZWIgMTkgMTE6MTMg
aA0KPiA+IC1ydy1yLS0tLS0gMSBzdGV2ZTYgc3VzZXVzZXJzICAgIDAgRmViIDE5IDExOjE5IGgy
DQo+ID4gaGgzOi9ob21lL0NBQ1RVUyAjIG5mczRfZ2V0ZmFjbCAvbW50L0NBQ1RVUy9kcm9wYm94
Lw0KPiA+IEE6Ok9XTkVSQDpyd2FEeHRUY0N5DQo+ID4gQTo6R1JPVVBAOnJ3YUR4dGN5DQo+ID4g
QTo6RVZFUllPTkVAOnRjeQ0KPiA+IEE6ZmRpOk9XTkVSQDpyd2FEeHRUY0N5DQo+ID4gQTpmZGk6
R1JPVVBAOnJ3YUR0Y3kNCj4gPiBBOmZkaTpFVkVSWU9ORUA6dGN5DQo+ID4gaGgzOi9ob21lL0NB
Q1RVUyAjIG5mczRfc2V0ZmFjbCAtYSBBOmZkaTpHUk9VUEA6UldYDQo+ID4gL21udC9DQUNUVVMv
ZHJvcGJveGhoMzovaG9tZS9DQUNUVVMgIyBuZnM0X2dldGZhY2wgL21udC9DQUNUVVMvZHJvcGJv
eC8NCj4gPiBBOjpPV05FUkA6cndhRHh0VGNDeQ0KPiA+IEE6OkdST1VQQDpyd2FEeHRjeQ0KPiA+
IEE6OkVWRVJZT05FQDp0Y3kNCj4gPiBBOmZkaTpPV05FUkA6cndhRHh0VGNDeQ0KPiA+IEE6ZmRp
OkdST1VQQDpyd2FEeHRjeQ0KPiA+IEE6ZmRpOkVWRVJZT05FQDp0Y3kNCj4gPg0KPiA+IHN0ZXZl
NkBoaDM6L21udC9DQUNUVVMvZHJvcGJveD4gdG91Y2ggaDMNCj4gPiBzdGV2ZTZAaGgzOi9tbnQv
Q0FDVFVTL2Ryb3Bib3g+IGxzIC1sYQ0KPiA+IHRvdGFsIDgNCj4gPiBkcnd4cndzLS0tIDIgcm9v
dCAgIHN1c2V1c2VycyA0MDk2IEZlYiAxOSAxMToyMSAuDQo+ID4gZHJ3eHIteHIteCA5IHJvb3Qg
ICByb290ICAgICAgNDA5NiBGZWIgMTkgMTE6MTEgLi4NCj4gPiAtcnctcnctLS0tIDEgc3RldmU2
IHN1c2V1c2VycyAgICAwIEZlYiAxOSAxMToxMyBoDQo+ID4gLXJ3LXItLS0tLSAxIHN0ZXZlNiBz
dXNldXNlcnMgICAgMCBGZWIgMTkgMTE6MTkgaDINCj4gPiAtcnctci0tLS0tIDEgc3RldmU2IHN1
c2V1c2VycyAgICAwIEZlYiAxOSAxMToyMSBoMw0KPiA+DQo+ID4gU3RpbGwgbm8gZ3JvdXAgcncg
b24gY3JlYXRlZCBmaWxlcy4gPSBuZnM0IGFjbCBpcyBub3Qgd29ya2luZyBhcw0KPiA+IGV4cGVj
dGVkLg0KPiA+DQo+ID4gV29ya2Fyb3VuZC4gR2V0IHRoZSBvdXQgdGhlIGJpZyBoYW1tZXI6DQo+
ID4gIyEvYmluL3NoDQo+ID4gd2hpbGUgdHJ1ZTsgZG8gJChjaG1vZCAtUiBnK3cgL2hvbWUvQ0FD
VFVTL2Ryb3Bib3gpOyBzbGVlcCAyOyBkb25lDQo+ID4NCj4gPiBRdWVzdGlvbjoNCj4gPiBXaGF0
IGFtIEkgbWlzc2luZz8gSG93IGRvIEkgc2V0IGZpbGVzIGNyZWF0ZWQgb24gYW4gbmZzNCBzaGFy
ZSB0byB0YWtlDQo+ID4gZ3JvdXAgcnc/DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gU3RldmUNCj4g
Pg0KPiA+IC0tDQo+ID4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxp
bmUgInVuc3Vic2NyaWJlIGxpbnV4LW5mcyIgaW4NCj4gPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2Ug
dG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0KPiA+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQg
IGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0KPiANCj4gLS0NCj4g
VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJl
IGxpbnV4LW5mcyIgaW4NCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2Vy
Lmtlcm5lbC5vcmcNCj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0cDovL3ZnZXIua2VybmVs
Lm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQoNCg==
On 23/02/12 17:08, steve wrote:
> On 02/23/2012 04:42 PM, J. Bruce Fields wrote:
>>>> First, if you want an ace on a directory to be inherited by files and
>>>> directories created under that directory, make sure you're setting
>>>> the f
>>>> and d flags (see nfs4_getfacl -H).
>>>>
>>>> Second, there's a umask problem: posix acl inheritance overrides the
>>>> umask, but nfs4 acl inheritance isn't doing that. (The client combines
>>>> the create mode and the umask and sets both together, there's no way
>>>> for
>>>> the server to even tell what the umask is.)
>>>>
>>>> (We should do something about this if we can: maybe modifying the
>>>> client
>>>> to scan the directory acl for any inheritable aces and leaving out the
>>>> umask if they're found? It has the obvious race, but I seem to recall
>>>> we live with that in the v3 case. Or maybe there's something more
>>>> clever, but this comes up every now and then and I can't remember a
>>>> better solution.)
>>>>
Hi everyone
This really is a show stopper for us.
Would it be possible to give users the choice of being able to disable
nfs4 acls so we can fall back to POSIX or nt acls? Or at least until the
nfs4 team have had time to consider the situation?
Mounting with -o nofacl in the hope that the POSIX acl set on the
unmounted directory would take effect, seems to have no effect.
What I'm doing at the moment is scanning the unmounted directory every
few seconds using 'find' and changing the files to g+rw:-(
Thanks,
Steve
On 02/29/2012 03:32 PM, J. Bruce Fields wrote:
> On Wed, Feb 29, 2012 at 03:26:33PM +0100, steve wrote:
>> On 02/29/2012 03:09 PM, J. Bruce Fields wrote:
>>> On Wed, Feb 29, 2012 at 03:04:28PM +0100, steve wrote:
>>>> On 29/02/12 13:44, J. Bruce Fields wrote:
>>>>> On Wed, Feb 29, 2012 at 12:22:30AM +0100, steve wrote:
>>>>>> We are authenticating against Samba4, so our domain user accounts
>>>>>> are under Kerberos.
>>>>> Kerberos works fine with v3.
>>>>>
>>>>> --b.
>>>> Hi
>>>> Unfortunately, it doesn't seem to. We just tried it, and anyone
>>>> (with or without a ticket) gets access:-(
>>> Could you give any more detail about your test?
>>>
>>> --b.
>> steve is a /etc/passwd user
>>
>> steve@hh3:~$ sudo su
>> [sudo] password for steve:
>> root@hh3:/home/steve# mount -t nfs4 hh3:/home /mnt -o sec=krb5
>> root@hh3:/home/steve# exit
>> exit
>> steve@hh3:~$ cd /mnt
>> bash: cd: /mnt: Permission denied
>> steve@hh3:~$ sudo su
>> root@hh3:/home/steve# umount /mnt
>> root@hh3:/home/steve# mount -t nfs hh3:/home /mnt -o sec=krb5
>> root@hh3:/home/steve# exit
>> exit
>> steve@hh3:~$ cd /mnt
>> steve@hh3:/mnt$
> Why is that a problem? You haven't actually accessed anything on the
> filesystem.
>
> --b.
Steve can access the mounted folder. I can live with that but the acl
still isn't working:
lynn2 has authinticated by Kerberos
root@hh3:~# setfacl -d -m g::rw /home/CACTUS/dropbox
root@hh3:~# mount -t nfs hh3:/home /mnt -o sec=krb5
lynn2@hh3:/mnt/CACTUS$ ls -la
total 28
drwxr-xr-x 6 root root 4096 2012-02-27 14:24 .
drwxr-xr-x 4 root root 4096 2012-02-18 18:52 ..
drwxrws--- 3 root debusers 4096 2012-02-29 15:31 dropbox
drwxr-xr-x 20 lynn2 debusers 4096 2012-02-26 16:43 lynn2
drwxrwxrwx 5 root root 4096 2012-02-29 14:19 profiles
drwxr-xr-x 4 steve2 Domain Users 4096 2012-02-29 14:36 steve2
lynn2 then crates a file in the mount called l3:
lynn2@hh3:/mnt/CACTUS$ ls -la /home/CACTUS/dropbox/
total 20
drwxrws---+ 3 root debusers 4096 2012-02-29 15:31 .
drwxr-xr-x 6 root root 4096 2012-02-27 14:24 ..
-rw-r----- 1 lynn2 debusers 0 2012-02-29 15:31 a
drwxrwS---+ 2 root debusers 4096 2012-02-29 14:28 adminfolder
-rw-rw---- 1 lynn2 debusers 0 2012-02-25 23:23 l2
-rw-r----- 1 lynn2 debusers 0 2012-02-29 15:24 l3
-rw-rw---- 1 lynn2 debusers 0 2012-02-26 16:20 lynn2-ubuntu.txt
-rw-rw---- 1 lynn2 debusers 11 2012-02-26 00:46 lynnnautilus.txt
??
Cheers,
Steve
On 18/02/12 21:08, steve wrote:
> Hi
> Is it possible for nfs4 to respect the acls I have setup on an ext4
> export?
> Thanks,
> Steve
>
> openSUSE 12.1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Sorry, this is what I've tried so far:
cat /etc/exports
/home
*(rw,no_root_squash,sec=none:sys:krb5:krb5i:krb5p,no_subtree_check,insecure)
1. Make a folder to share:
hh3:/home/CACTUS # mkdir -m 770 dropbox
hh3:/home/CACTUS # chown root:suseusers dropbox
2. Mount the share:
hh3:/home/CACTUS # mount -t nfs4 hh3:/home /mnt
3. Look at the acls:
nfs4_getfacl /mnt/CACTUS/dropbox
A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A::EVERYONE@:tcy
Set an acl so that members of suseusers have rw on the share:
hh3:/home/CACTUS # nfs4_setfacl -a A:g:[email protected]:RW
/mnt/CACTUS/dropbox
hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A:g:[email protected]:rwaDtcy
A::EVERYONE@:tcy
4. Yes. Back in the unmounted directory, the acl + has appeared:
hh3:/home/CACTUS # ls -la dropbox/
total 8
drwxrwx---+ 2 root suseusers 4096 Feb 19 10:55 .
drwxr-xr-x 9 root root 4096 Feb 19 10:55 ..
5. On the mounted share, the acl is not visible. steve6 can create a
file but it is _not_ group rw:
steve6@hh3:~> cd /mnt/CACTUS/dropbox/
steve6@hh3:/mnt/CACTUS/dropbox> touch hola.txt
steve6@hh3:/mnt/CACTUS/dropbox> ls -la
total 8
drwxrwx--- 2 root suseusers 4096 Feb 19 11:02 .
drwxr-xr-x 9 root root 4096 Feb 19 10:55 ..
-rw-r--r-- 1 steve6 suseusers 0 Feb 19 11:02 hola.txt
6. Recreate the share but this time with a posix acl:
setfacl -d -m g::rw /home/CACTUS/dropbox
steve6@hh3:/home/CACTUS> touch dropbox/h
steve6@hh3:/home/CACTUS> ls -la dropbox/
total 8
drwxrws---+ 2 root suseusers 4096 Feb 19 11:13 .
drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
-rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
Yes. Now when steve6 creates a file it _is_ group rw. = posix acl is
working.
7. Mount the new posix share and test again:
hh3:/home/CACTUS #chmod g+s /home/CACTUS/dropbox
hh3:/home/CACTUS # mount -t nfs4 hh3:/home /mnt
hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:GROUP@:rwaDtcy
A:fdi:EVERYONE@:tcy
steve6@hh3:/mnt/CACTUS/dropbox> touch h2
steve6@hh3:/mnt/CACTUS/dropbox> ls -la
total 8
drwxrws--- 2 root suseusers 4096 Feb 19 11:19 .
drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
-rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
-rw-r----- 1 steve6 suseusers 0 Feb 19 11:19 h2
hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:GROUP@:rwaDtcy
A:fdi:EVERYONE@:tcy
hh3:/home/CACTUS # nfs4_setfacl -a A:fdi:GROUP@:RWX
/mnt/CACTUS/dropboxhh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:GROUP@:rwaDxtcy
A:fdi:EVERYONE@:tcy
steve6@hh3:/mnt/CACTUS/dropbox> touch h3
steve6@hh3:/mnt/CACTUS/dropbox> ls -la
total 8
drwxrws--- 2 root suseusers 4096 Feb 19 11:21 .
drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
-rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
-rw-r----- 1 steve6 suseusers 0 Feb 19 11:19 h2
-rw-r----- 1 steve6 suseusers 0 Feb 19 11:21 h3
Still no group rw on created files. = nfs4 acl is not working as expected.
Workaround. Get the out the big hammer:
#!/bin/sh
while true; do $(chmod -R g+w /home/CACTUS/dropbox); sleep 2; done
Question:
What am I missing? How do I set files created on an nfs4 share to take
group rw?
Thanks,
Steve
On Thu, Feb 23, 2012 at 12:53:28PM +0100, steve wrote:
> Hi Jeff
> Thanks for the reply. I'm trying to make the files created in a
> share take on group rw.
>
> The trouble is that I've already tried setting the acl's via
> nfs4_setfacl on the mounted share too (please see details below).
> The acl + appears on the unmounted share and behaves as expected
> even when it is not mounted. The mounted share however ignores the
> acl I've set. I've tried remounting but still no acl is effective.
> My workaround is to scan the folder and change the files to group rw
> every few seconds.
Without looking at your details, apologies:
First, if you want an ace on a directory to be inherited by files and
directories created under that directory, make sure you're setting the f
and d flags (see nfs4_getfacl -H).
Second, there's a umask problem: posix acl inheritance overrides the
umask, but nfs4 acl inheritance isn't doing that. (The client combines
the create mode and the umask and sets both together, there's no way for
the server to even tell what the umask is.)
(We should do something about this if we can: maybe modifying the client
to scan the directory acl for any inheritable aces and leaving out the
umask if they're found? It has the obvious race, but I seem to recall
we live with that in the v3 case. Or maybe there's something more
clever, but this comes up every now and then and I can't remember a
better solution.)
--b.
On 02/23/2012 04:42 PM, J. Bruce Fields wrote:
> On Thu, Feb 23, 2012 at 04:33:14PM +0100, steve wrote:
>> On 02/23/2012 03:40 PM, J. Bruce Fields wrote:
>>> On Thu, Feb 23, 2012 at 12:53:28PM +0100, steve wrote:
>>>> Hi Jeff
>>>> Thanks for the reply. I'm trying to make the files created in a
>>>> share take on group rw.
>>>>
>>>> The trouble is that I've already tried setting the acl's via
>>>> nfs4_setfacl on the mounted share too (please see details below).
>>>> The acl + appears on the unmounted share and behaves as expected
>>>> even when it is not mounted. The mounted share however ignores the
>>>> acl I've set. I've tried remounting but still no acl is effective.
>>>> My workaround is to scan the folder and change the files to group rw
>>>> every few seconds.
>>> Without looking at your details, apologies:
>>>
>>> First, if you want an ace on a directory to be inherited by files and
>>> directories created under that directory, make sure you're setting the f
>>> and d flags (see nfs4_getfacl -H).
>>>
>>> Second, there's a umask problem: posix acl inheritance overrides the
>>> umask, but nfs4 acl inheritance isn't doing that. (The client combines
>>> the create mode and the umask and sets both together, there's no way for
>>> the server to even tell what the umask is.)
>>>
>>> (We should do something about this if we can: maybe modifying the client
>>> to scan the directory acl for any inheritable aces and leaving out the
>>> umask if they're found? It has the obvious race, but I seem to recall
>>> we live with that in the v3 case. Or maybe there's something more
>>> clever, but this comes up every now and then and I can't remember a
>>> better solution.)
>>>
>>> --b.
>> Hi again
>> I have this:
>> nfs4_getfacl /mnt/CACTUS/dropbox/
>>
>> A::OWNER@:rwaDxtTcCy
>> A::GROUP@:rwaDxtcy
>> A::EVERYONE@:tcy
>> A:fdi:OWNER@:rwaDxtTcCy
>> A:fdi:GROUP@:rwaDtcy
>> A:fdi:EVERYONE@:tcy
>>
>> but files are created:
>> steve6@hh3:/mnt/CACTUS/dropbox> touch h3
>> ls -la
>> total 8
>> drwxrws--- 2 root suseusers 4096 Feb 19 11:21 .
>> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
>> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
>> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:21 h3
>>
>> where h is a file created on the unmounted share and h3 on the nfs4
>> mounted share. IOW the file created does not have group rw.
>> Ahhgghh!!
> Right, so see the second point above: what's your umask? (output of the
> "umask" command.)
>
> --b.
>
>> Can anyone see anything wrong?
>>
>> Thanks so much for your patience.
>> Steve.
>>
OK. I see what you mean. umask 0022
So I can have a group rw with posix but not with nfs4_setfacl:-(
That's on openSUSE who default to 0022. The default on Ubuntu is 0002 so
presumably we could have group rw over nfs4 there out of the box?
Is it a lot of work to implement umask override for nfs4? Or make it an
option perhaps?
At the moment I'm using a big hammer and scanning the share every 4
seconds to change the permissions of any files created there. My other
thought was to have the share on a different partition, umask it to 0002
and export that. But these are workarounds. It would be really good to
have the nfs4 acls do it.
Thanks again,
Steve
On Wed, Feb 29, 2012 at 12:22:30AM +0100, steve wrote:
> We are authenticating against Samba4, so our domain user accounts
> are under Kerberos.
Kerberos works fine with v3.
--b.
> We could wait for the s4 cifs fileserver and
> winbind to be ready but would rather stick with nfs for our Linux
> clients. Simple reason being that it beats cifs on speed, especially
> when the lan is busy.
>
> Is there an option to turn off the nfs4 acl's? I see that there is a
> -o noacl mount option but it seems to have no effect for us.
>
> Guys, basically we don't know where to turn next. We have this issue
> open here, and on the samba and openSUSE lists. Is there anyway we
> can get together to thrash this out?
>
> Thanks so much for replying.
> Cheers,
> Steve pp the Spanish team at lcb
>
>
> >
> >--b.
> >
> >>Mounting with -o nofacl in the hope that the POSIX acl set on the
> >>unmounted directory would take effect, seems to have no effect.
> >>
> >>What I'm doing at the moment is scanning the unmounted directory
> >>every few seconds using 'find' and changing the files to g+rw:-(
> >>
> >>Thanks,
> >>Steve
> >>--
> >>To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>the body of a message to [email protected]
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Wed, Feb 29, 2012 at 03:26:33PM +0100, steve wrote:
> On 02/29/2012 03:09 PM, J. Bruce Fields wrote:
> >On Wed, Feb 29, 2012 at 03:04:28PM +0100, steve wrote:
> >>On 29/02/12 13:44, J. Bruce Fields wrote:
> >>>On Wed, Feb 29, 2012 at 12:22:30AM +0100, steve wrote:
> >>>>We are authenticating against Samba4, so our domain user accounts
> >>>>are under Kerberos.
> >>>Kerberos works fine with v3.
> >>>
> >>>--b.
> >>Hi
> >>Unfortunately, it doesn't seem to. We just tried it, and anyone
> >>(with or without a ticket) gets access:-(
> >Could you give any more detail about your test?
> >
> >--b.
> steve is a /etc/passwd user
>
> steve@hh3:~$ sudo su
> [sudo] password for steve:
> root@hh3:/home/steve# mount -t nfs4 hh3:/home /mnt -o sec=krb5
> root@hh3:/home/steve# exit
> exit
> steve@hh3:~$ cd /mnt
> bash: cd: /mnt: Permission denied
> steve@hh3:~$ sudo su
> root@hh3:/home/steve# umount /mnt
> root@hh3:/home/steve# mount -t nfs hh3:/home /mnt -o sec=krb5
> root@hh3:/home/steve# exit
> exit
> steve@hh3:~$ cd /mnt
> steve@hh3:/mnt$
Why is that a problem? You haven't actually accessed anything on the
filesystem.
--b.
On Thu, Feb 23, 2012 at 04:33:14PM +0100, steve wrote:
> On 02/23/2012 03:40 PM, J. Bruce Fields wrote:
> >On Thu, Feb 23, 2012 at 12:53:28PM +0100, steve wrote:
> >>Hi Jeff
> >>Thanks for the reply. I'm trying to make the files created in a
> >>share take on group rw.
> >>
> >>The trouble is that I've already tried setting the acl's via
> >>nfs4_setfacl on the mounted share too (please see details below).
> >>The acl + appears on the unmounted share and behaves as expected
> >>even when it is not mounted. The mounted share however ignores the
> >>acl I've set. I've tried remounting but still no acl is effective.
> >>My workaround is to scan the folder and change the files to group rw
> >>every few seconds.
> >Without looking at your details, apologies:
> >
> >First, if you want an ace on a directory to be inherited by files and
> >directories created under that directory, make sure you're setting the f
> >and d flags (see nfs4_getfacl -H).
> >
> >Second, there's a umask problem: posix acl inheritance overrides the
> >umask, but nfs4 acl inheritance isn't doing that. (The client combines
> >the create mode and the umask and sets both together, there's no way for
> >the server to even tell what the umask is.)
> >
> >(We should do something about this if we can: maybe modifying the client
> >to scan the directory acl for any inheritable aces and leaving out the
> >umask if they're found? It has the obvious race, but I seem to recall
> >we live with that in the v3 case. Or maybe there's something more
> >clever, but this comes up every now and then and I can't remember a
> >better solution.)
> >
> >--b.
> Hi again
> I have this:
> nfs4_getfacl /mnt/CACTUS/dropbox/
>
> A::OWNER@:rwaDxtTcCy
> A::GROUP@:rwaDxtcy
> A::EVERYONE@:tcy
> A:fdi:OWNER@:rwaDxtTcCy
> A:fdi:GROUP@:rwaDtcy
> A:fdi:EVERYONE@:tcy
>
> but files are created:
> steve6@hh3:/mnt/CACTUS/dropbox> touch h3
> ls -la
> total 8
> drwxrws--- 2 root suseusers 4096 Feb 19 11:21 .
> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:21 h3
>
> where h is a file created on the unmounted share and h3 on the nfs4
> mounted share. IOW the file created does not have group rw.
> Ahhgghh!!
Right, so see the second point above: what's your umask? (output of the
"umask" command.)
--b.
>
> Can anyone see anything wrong?
>
> Thanks so much for your patience.
> Steve.
>
On 02/23/2012 03:40 PM, J. Bruce Fields wrote:
> On Thu, Feb 23, 2012 at 12:53:28PM +0100, steve wrote:
>> Hi Jeff
>> Thanks for the reply. I'm trying to make the files created in a
>> share take on group rw.
>>
>> The trouble is that I've already tried setting the acl's via
>> nfs4_setfacl on the mounted share too (please see details below).
>> The acl + appears on the unmounted share and behaves as expected
>> even when it is not mounted. The mounted share however ignores the
>> acl I've set. I've tried remounting but still no acl is effective.
>> My workaround is to scan the folder and change the files to group rw
>> every few seconds.
> Without looking at your details, apologies:
>
> First, if you want an ace on a directory to be inherited by files and
> directories created under that directory, make sure you're setting the f
> and d flags (see nfs4_getfacl -H).
>
> Second, there's a umask problem: posix acl inheritance overrides the
> umask, but nfs4 acl inheritance isn't doing that. (The client combines
> the create mode and the umask and sets both together, there's no way for
> the server to even tell what the umask is.)
>
> (We should do something about this if we can: maybe modifying the client
> to scan the directory acl for any inheritable aces and leaving out the
> umask if they're found? It has the obvious race, but I seem to recall
> we live with that in the v3 case. Or maybe there's something more
> clever, but this comes up every now and then and I can't remember a
> better solution.)
>
> --b.
Hi again
I have this:
nfs4_getfacl /mnt/CACTUS/dropbox/
A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:GROUP@:rwaDtcy
A:fdi:EVERYONE@:tcy
but files are created:
steve6@hh3:/mnt/CACTUS/dropbox> touch h3
ls -la
total 8
drwxrws--- 2 root suseusers 4096 Feb 19 11:21 .
drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
-rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
-rw-r----- 1 steve6 suseusers 0 Feb 19 11:21 h3
where h is a file created on the unmounted share and h3 on the nfs4
mounted share. IOW the file created does not have group rw. Ahhgghh!!
Can anyone see anything wrong?
Thanks so much for your patience.
Steve.
On 02/28/2012 09:05 PM, J. Bruce Fields wrote:
> On Sat, Feb 25, 2012 at 09:19:37AM +0100, steve wrote:
>> On 23/02/12 17:08, steve wrote:
>>> On 02/23/2012 04:42 PM, J. Bruce Fields wrote:
>>>>>> First, if you want an ace on a directory to be inherited by files and
>>>>>> directories created under that directory, make sure you're setting
>>>>>> the f
>>>>>> and d flags (see nfs4_getfacl -H).
>>>>>>
>>>>>> Second, there's a umask problem: posix acl inheritance overrides the
>>>>>> umask, but nfs4 acl inheritance isn't doing that. (The client combines
>>>>>> the create mode and the umask and sets both together, there's no way
>>>>>> for
>>>>>> the server to even tell what the umask is.)
>>>>>>
>>>>>> (We should do something about this if we can: maybe modifying the
>>>>>> client
>>>>>> to scan the directory acl for any inheritable aces and leaving out the
>>>>>> umask if they're found? It has the obvious race, but I seem to recall
>>>>>> we live with that in the v3 case. Or maybe there's something more
>>>>>> clever, but this comes up every now and then and I can't remember a
>>>>>> better solution.)
>>>>>>
>> Hi everyone
>>
>> This really is a show stopper for us.
>>
>> Would it be possible to give users the choice of being able to
>> disable nfs4 acls so we can fall back to POSIX or nt acls? Or at
>> least until the nfs4 team have had time to consider the situation?
> The NFSv4 protocol has no support for posix acls, so this isn't an
> option; possibly you're best off with v3 for some reason. (Why the
> migration to v4?)
We are authenticating against Samba4, so our domain user accounts are
under Kerberos. We could wait for the s4 cifs fileserver and winbind to
be ready but would rather stick with nfs for our Linux clients. Simple
reason being that it beats cifs on speed, especially when the lan is busy.
Is there an option to turn off the nfs4 acl's? I see that there is a -o
noacl mount option but it seems to have no effect for us.
Guys, basically we don't know where to turn next. We have this issue
open here, and on the samba and openSUSE lists. Is there anyway we can
get together to thrash this out?
Thanks so much for replying.
Cheers,
Steve pp the Spanish team at lcb
>
> --b.
>
>> Mounting with -o nofacl in the hope that the POSIX acl set on the
>> unmounted directory would take effect, seems to have no effect.
>>
>> What I'm doing at the moment is scanning the unmounted directory
>> every few seconds using 'find' and changing the files to g+rw:-(
>>
>> Thanks,
>> Steve
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 29, 2012 at 03:04:28PM +0100, steve wrote:
> On 29/02/12 13:44, J. Bruce Fields wrote:
> >On Wed, Feb 29, 2012 at 12:22:30AM +0100, steve wrote:
> >>We are authenticating against Samba4, so our domain user accounts
> >>are under Kerberos.
> >
> >Kerberos works fine with v3.
> >
> >--b.
>
> Hi
> Unfortunately, it doesn't seem to. We just tried it, and anyone
> (with or without a ticket) gets access:-(
Could you give any more detail about your test?
--b.
Hi everyone
I'm sorry to bump this but I've tried the opensuse, ubuntu and samba
lists without any luck.
The acls I have created are not inherited when exporting via nfs4. Can
anyone help me with this? Tell me it can/can't be done? Versions of nfs
to use? Details below.
Thanks,
Steve
On 02/19/2012 06:15 PM, steve wrote:
> On 18/02/12 21:08, steve wrote:
>> Hi
>> Is it possible for nfs4 to respect the acls I have setup on an ext4
>> export?
>> Thanks,
>> Steve
>>
>> openSUSE 12.1
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Sorry, this is what I've tried so far:
> cat /etc/exports
> /home
> *(rw,no_root_squash,sec=none:sys:krb5:krb5i:krb5p,no_subtree_check,insecure)
>
> 1. Make a folder to share:
> hh3:/home/CACTUS # mkdir -m 770 dropbox
> hh3:/home/CACTUS # chown root:suseusers dropbox
>
> 2. Mount the share:
> hh3:/home/CACTUS # mount -t nfs4 hh3:/home /mnt
>
> 3. Look at the acls:
> nfs4_getfacl /mnt/CACTUS/dropbox
> A::OWNER@:rwaDxtTcCy
> A::GROUP@:rwaDxtcy
> A::EVERYONE@:tcy
>
> Set an acl so that members of suseusers have rw on the share:
> hh3:/home/CACTUS # nfs4_setfacl -a A:g:[email protected]:RW
> /mnt/CACTUS/dropbox
>
> hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
> A::OWNER@:rwaDxtTcCy
> A::GROUP@:rwaDxtcy
> A:g:[email protected]:rwaDtcy
> A::EVERYONE@:tcy
>
> 4. Yes. Back in the unmounted directory, the acl + has appeared:
> hh3:/home/CACTUS # ls -la dropbox/
> total 8
> drwxrwx---+ 2 root suseusers 4096 Feb 19 10:55 .
> drwxr-xr-x 9 root root 4096 Feb 19 10:55 ..
>
> 5. On the mounted share, the acl is not visible. steve6 can create a
> file but it is _not_ group rw:
> steve6@hh3:~> cd /mnt/CACTUS/dropbox/
> steve6@hh3:/mnt/CACTUS/dropbox> touch hola.txt
> steve6@hh3:/mnt/CACTUS/dropbox> ls -la
> total 8
> drwxrwx--- 2 root suseusers 4096 Feb 19 11:02 .
> drwxr-xr-x 9 root root 4096 Feb 19 10:55 ..
> -rw-r--r-- 1 steve6 suseusers 0 Feb 19 11:02 hola.txt
>
> 6. Recreate the share but this time with a posix acl:
> setfacl -d -m g::rw /home/CACTUS/dropbox
> steve6@hh3:/home/CACTUS> touch dropbox/h
> steve6@hh3:/home/CACTUS> ls -la dropbox/
> total 8
> drwxrws---+ 2 root suseusers 4096 Feb 19 11:13 .
> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
>
> Yes. Now when steve6 creates a file it _is_ group rw. = posix acl is
> working.
>
> 7. Mount the new posix share and test again:
> hh3:/home/CACTUS #chmod g+s /home/CACTUS/dropbox
> hh3:/home/CACTUS # mount -t nfs4 hh3:/home /mnt
> hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
> A::OWNER@:rwaDxtTcCy
> A::GROUP@:rwaDxtcy
> A::EVERYONE@:tcy
> A:fdi:OWNER@:rwaDxtTcCy
> A:fdi:GROUP@:rwaDtcy
> A:fdi:EVERYONE@:tcy
>
> steve6@hh3:/mnt/CACTUS/dropbox> touch h2
> steve6@hh3:/mnt/CACTUS/dropbox> ls -la
> total 8
> drwxrws--- 2 root suseusers 4096 Feb 19 11:19 .
> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:19 h2
> hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
> A::OWNER@:rwaDxtTcCy
> A::GROUP@:rwaDxtcy
> A::EVERYONE@:tcy
> A:fdi:OWNER@:rwaDxtTcCy
> A:fdi:GROUP@:rwaDtcy
> A:fdi:EVERYONE@:tcy
> hh3:/home/CACTUS # nfs4_setfacl -a A:fdi:GROUP@:RWX
> /mnt/CACTUS/dropboxhh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
> A::OWNER@:rwaDxtTcCy
> A::GROUP@:rwaDxtcy
> A::EVERYONE@:tcy
> A:fdi:OWNER@:rwaDxtTcCy
> A:fdi:GROUP@:rwaDxtcy
> A:fdi:EVERYONE@:tcy
>
> steve6@hh3:/mnt/CACTUS/dropbox> touch h3
> steve6@hh3:/mnt/CACTUS/dropbox> ls -la
> total 8
> drwxrws--- 2 root suseusers 4096 Feb 19 11:21 .
> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:19 h2
> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:21 h3
>
> Still no group rw on created files. = nfs4 acl is not working as
> expected.
>
> Workaround. Get the out the big hammer:
> #!/bin/sh
> while true; do $(chmod -R g+w /home/CACTUS/dropbox); sleep 2; done
>
> Question:
> What am I missing? How do I set files created on an nfs4 share to take
> group rw?
>
> Thanks,
> Steve
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 23 Feb 2012 08:15:26 +0100
steve <[email protected]> wrote:
> Hi everyone
> I'm sorry to bump this but I've tried the opensuse, ubuntu and samba
> lists without any luck.
>
> The acls I have created are not inherited when exporting via nfs4. Can
> anyone help me with this? Tell me it can/can't be done? Versions of nfs
> to use? Details below.
> Thanks,
> Steve
>
>
The NFSv4 protocol does not support POSIX ACLs. It has its own
implementation of ACLs that is much more windows-like (yet not exactly
either).
For enforcement, it doesn't really matter too much -- the server
enforces POSIX ACLs since that's done within the VFS and local
filesystem. The only "problem" is that you can't see and manipulate
ACLs directly over NFSv4 using standard POSIX acl tools.
You can view and manipulate NFSv4 ACLs using the programs in the
nfs4-acl-tools package. Linux' nfsd will map those to/from POSIX ACLs
but it's always going to be a lossy mapping.
There are also patches in progress to add the ability for Linux
filesystems to support NFSv4/Windows ACLs natively. That effort is
called RichACLs, but it's not in mainline yet, and development on it
seems to have stalled of late.
> On 02/19/2012 06:15 PM, steve wrote:
> > On 18/02/12 21:08, steve wrote:
> >> Hi
> >> Is it possible for nfs4 to respect the acls I have setup on an ext4
> >> export?
> >> Thanks,
> >> Steve
> >>
> >> openSUSE 12.1
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Sorry, this is what I've tried so far:
> > cat /etc/exports
> > /home
> > *(rw,no_root_squash,sec=none:sys:krb5:krb5i:krb5p,no_subtree_check,insecure)
> >
> > 1. Make a folder to share:
> > hh3:/home/CACTUS # mkdir -m 770 dropbox
> > hh3:/home/CACTUS # chown root:suseusers dropbox
> >
> > 2. Mount the share:
> > hh3:/home/CACTUS # mount -t nfs4 hh3:/home /mnt
> >
> > 3. Look at the acls:
> > nfs4_getfacl /mnt/CACTUS/dropbox
> > A::OWNER@:rwaDxtTcCy
> > A::GROUP@:rwaDxtcy
> > A::EVERYONE@:tcy
> >
> > Set an acl so that members of suseusers have rw on the share:
> > hh3:/home/CACTUS # nfs4_setfacl -a A:g:[email protected]:RW
> > /mnt/CACTUS/dropbox
> >
> > hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
> > A::OWNER@:rwaDxtTcCy
> > A::GROUP@:rwaDxtcy
> > A:g:[email protected]:rwaDtcy
> > A::EVERYONE@:tcy
> >
> > 4. Yes. Back in the unmounted directory, the acl + has appeared:
> > hh3:/home/CACTUS # ls -la dropbox/
> > total 8
> > drwxrwx---+ 2 root suseusers 4096 Feb 19 10:55 .
> > drwxr-xr-x 9 root root 4096 Feb 19 10:55 ..
> >
> > 5. On the mounted share, the acl is not visible. steve6 can create a
> > file but it is _not_ group rw:
> > steve6@hh3:~> cd /mnt/CACTUS/dropbox/
> > steve6@hh3:/mnt/CACTUS/dropbox> touch hola.txt
> > steve6@hh3:/mnt/CACTUS/dropbox> ls -la
> > total 8
> > drwxrwx--- 2 root suseusers 4096 Feb 19 11:02 .
> > drwxr-xr-x 9 root root 4096 Feb 19 10:55 ..
> > -rw-r--r-- 1 steve6 suseusers 0 Feb 19 11:02 hola.txt
> >
> > 6. Recreate the share but this time with a posix acl:
> > setfacl -d -m g::rw /home/CACTUS/dropbox
> > steve6@hh3:/home/CACTUS> touch dropbox/h
> > steve6@hh3:/home/CACTUS> ls -la dropbox/
> > total 8
> > drwxrws---+ 2 root suseusers 4096 Feb 19 11:13 .
> > drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
> > -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
> >
> > Yes. Now when steve6 creates a file it _is_ group rw. = posix acl is
> > working.
> >
> > 7. Mount the new posix share and test again:
> > hh3:/home/CACTUS #chmod g+s /home/CACTUS/dropbox
> > hh3:/home/CACTUS # mount -t nfs4 hh3:/home /mnt
> > hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
> > A::OWNER@:rwaDxtTcCy
> > A::GROUP@:rwaDxtcy
> > A::EVERYONE@:tcy
> > A:fdi:OWNER@:rwaDxtTcCy
> > A:fdi:GROUP@:rwaDtcy
> > A:fdi:EVERYONE@:tcy
> >
> > steve6@hh3:/mnt/CACTUS/dropbox> touch h2
> > steve6@hh3:/mnt/CACTUS/dropbox> ls -la
> > total 8
> > drwxrws--- 2 root suseusers 4096 Feb 19 11:19 .
> > drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
> > -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
> > -rw-r----- 1 steve6 suseusers 0 Feb 19 11:19 h2
> > hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
> > A::OWNER@:rwaDxtTcCy
> > A::GROUP@:rwaDxtcy
> > A::EVERYONE@:tcy
> > A:fdi:OWNER@:rwaDxtTcCy
> > A:fdi:GROUP@:rwaDtcy
> > A:fdi:EVERYONE@:tcy
> > hh3:/home/CACTUS # nfs4_setfacl -a A:fdi:GROUP@:RWX
> > /mnt/CACTUS/dropboxhh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
> > A::OWNER@:rwaDxtTcCy
> > A::GROUP@:rwaDxtcy
> > A::EVERYONE@:tcy
> > A:fdi:OWNER@:rwaDxtTcCy
> > A:fdi:GROUP@:rwaDxtcy
> > A:fdi:EVERYONE@:tcy
> >
> > steve6@hh3:/mnt/CACTUS/dropbox> touch h3
> > steve6@hh3:/mnt/CACTUS/dropbox> ls -la
> > total 8
> > drwxrws--- 2 root suseusers 4096 Feb 19 11:21 .
> > drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
> > -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
> > -rw-r----- 1 steve6 suseusers 0 Feb 19 11:19 h2
> > -rw-r----- 1 steve6 suseusers 0 Feb 19 11:21 h3
> >
> > Still no group rw on created files. = nfs4 acl is not working as
> > expected.
> >
> > Workaround. Get the out the big hammer:
> > #!/bin/sh
> > while true; do $(chmod -R g+w /home/CACTUS/dropbox); sleep 2; done
> >
> > Question:
> > What am I missing? How do I set files created on an nfs4 share to take
> > group rw?
> >
> > Thanks,
> > Steve
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jeff Layton <[email protected]>
On Thu, Feb 23, 2012 at 05:08:07PM +0100, steve wrote:
> OK. I see what you mean. umask 0022
> So I can have a group rw with posix but not with nfs4_setfacl:-(
>
> That's on openSUSE who default to 0022. The default on Ubuntu is
> 0002 so presumably we could have group rw over nfs4 there out of the
> box?
>
> Is it a lot of work to implement umask override for nfs4? Or make it
> an option perhaps?
Two fulltime-kernel-hacker-week-equivalents?
I'm not sure, I just made that up.
It does appear that it's necessary to make v4 ACLs usable in a lot of
cases.
--b.
> At the moment I'm using a big hammer and scanning the share every 4
> seconds to change the permissions of any files created there. My
> other thought was to have the share on a different partition, umask
> it to 0002 and export that. But these are workarounds. It would be
> really good to have the nfs4 acls do it.
On 29/02/12 13:44, J. Bruce Fields wrote:
> On Wed, Feb 29, 2012 at 12:22:30AM +0100, steve wrote:
>> We are authenticating against Samba4, so our domain user accounts
>> are under Kerberos.
>
> Kerberos works fine with v3.
>
> --b.
Hi
Unfortunately, it doesn't seem to. We just tried it, and anyone (with or
without a ticket) gets access:-(
Still hoping!
Steve
On 02/29/2012 03:09 PM, J. Bruce Fields wrote:
> On Wed, Feb 29, 2012 at 03:04:28PM +0100, steve wrote:
>> On 29/02/12 13:44, J. Bruce Fields wrote:
>>> On Wed, Feb 29, 2012 at 12:22:30AM +0100, steve wrote:
>>>> We are authenticating against Samba4, so our domain user accounts
>>>> are under Kerberos.
>>> Kerberos works fine with v3.
>>>
>>> --b.
>> Hi
>> Unfortunately, it doesn't seem to. We just tried it, and anyone
>> (with or without a ticket) gets access:-(
> Could you give any more detail about your test?
>
> --b.
steve is a /etc/passwd user
steve@hh3:~$ sudo su
[sudo] password for steve:
root@hh3:/home/steve# mount -t nfs4 hh3:/home /mnt -o sec=krb5
root@hh3:/home/steve# exit
exit
steve@hh3:~$ cd /mnt
bash: cd: /mnt: Permission denied
steve@hh3:~$ sudo su
root@hh3:/home/steve# umount /mnt
root@hh3:/home/steve# mount -t nfs hh3:/home /mnt -o sec=krb5
root@hh3:/home/steve# exit
exit
steve@hh3:~$ cd /mnt
steve@hh3:/mnt$
Cheers
On 02/23/2012 09:33 AM, [email protected] wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of steve
>> Sent: Thursday, February 23, 2012 3:15 PM
>> To: [email protected]
>> Subject: Re: POSIX acls over nfs4
>>
>> Hi everyone
>> I'm sorry to bump this but I've tried the opensuse, ubuntu and samba
>> lists without any luck.
> Not reading the details in your setup, but maybe following summary can help you a bit.
> http://www.suse.de/~agruen/acl/linux-acls/online/
>
> Cheers,
> Tao
Hi
Thanks for the link.
I used nfs4_setfacl to set the share to group rw. The acl works on the
unmounted ext4 folder (files created in the share become -rw-rw-) but
does not work when the share wen mounted via nfs4. Could this be a bug?
Thanks,
Steve
On 03/01/2012 09:56 PM, J. Bruce Fields wrote:
> On Wed, Feb 29, 2012 at 03:40:39PM +0100, steve wrote:
>> On 02/29/2012 03:32 PM, J. Bruce Fields wrote:
>>> On Wed, Feb 29, 2012 at 03:26:33PM +0100, steve wrote:
>>>> On 02/29/2012 03:09 PM, J. Bruce Fields wrote:
>>>>> On Wed, Feb 29, 2012 at 03:04:28PM +0100, steve wrote:
>>>>>> On 29/02/12 13:44, J. Bruce Fields wrote:
>>>>>>> On Wed, Feb 29, 2012 at 12:22:30AM +0100, steve wrote:
>>>>>>>> We are authenticating against Samba4, so our domain user accounts
>>>>>>>> are under Kerberos.
>>>>>>> Kerberos works fine with v3.
>>>>>>>
>>>>>>> --b.
>>>>>> Hi
>>>>>> Unfortunately, it doesn't seem to. We just tried it, and anyone
>>>>>> (with or without a ticket) gets access:-(
>>>>> Could you give any more detail about your test?
>>>>>
>>>>> --b.
>>>> steve is a /etc/passwd user
>>>>
>>>> steve@hh3:~$ sudo su
>>>> [sudo] password for steve:
>>>> root@hh3:/home/steve# mount -t nfs4 hh3:/home /mnt -o sec=krb5
>>>> root@hh3:/home/steve# exit
>>>> exit
>>>> steve@hh3:~$ cd /mnt
>>>> bash: cd: /mnt: Permission denied
>>>> steve@hh3:~$ sudo su
>>>> root@hh3:/home/steve# umount /mnt
>>>> root@hh3:/home/steve# mount -t nfs hh3:/home /mnt -o sec=krb5
> Careful: a recent client will negotiate v4 if you leave this
> unspecified. You want -onfsversion=3,sec=krb5.
>
>>>> root@hh3:/home/steve# exit
>>>> exit
>>>> steve@hh3:~$ cd /mnt
>>>> steve@hh3:/mnt$
>>> Why is that a problem? You haven't actually accessed anything on the
>>> filesystem.
>>>
>>> --b.
>> Steve can access the mounted folder. I can live with that but the
>> acl still isn't working:
>>
>> lynn2 has authinticated by Kerberos
>>
>> root@hh3:~# setfacl -d -m g::rw /home/CACTUS/dropbox
>> root@hh3:~# mount -t nfs hh3:/home /mnt -o sec=krb5
>> lynn2@hh3:/mnt/CACTUS$ ls -la
>> total 28
>> drwxr-xr-x 6 root root 4096 2012-02-27 14:24 .
>> drwxr-xr-x 4 root root 4096 2012-02-18 18:52 ..
>> drwxrws--- 3 root debusers 4096 2012-02-29 15:31 dropbox
>> drwxr-xr-x 20 lynn2 debusers 4096 2012-02-26 16:43 lynn2
>> drwxrwxrwx 5 root root 4096 2012-02-29 14:19 profiles
>> drwxr-xr-x 4 steve2 Domain Users 4096 2012-02-29 14:36 steve2
>>
>> lynn2 then crates a file in the mount called l3:
>>
>> lynn2@hh3:/mnt/CACTUS$ ls -la /home/CACTUS/dropbox/
>> total 20
>> drwxrws---+ 3 root debusers 4096 2012-02-29 15:31 .
>> drwxr-xr-x 6 root root 4096 2012-02-27 14:24 ..
>> -rw-r----- 1 lynn2 debusers 0 2012-02-29 15:31 a
>> drwxrwS---+ 2 root debusers 4096 2012-02-29 14:28 adminfolder
>> -rw-rw---- 1 lynn2 debusers 0 2012-02-25 23:23 l2
>> -rw-r----- 1 lynn2 debusers 0 2012-02-29 15:24 l3
>> -rw-rw---- 1 lynn2 debusers 0 2012-02-26 16:20 lynn2-ubuntu.txt
>> -rw-rw---- 1 lynn2 debusers 11 2012-02-26 00:46 lynnnautilus.txt
>>
>> ??
> I would have expected the default acl on the parent to override any
> umask on v3.
>
> So if it's actually v3, then that looks like a bug to me.
>
> --b.
Hi
Your expectation helps a lot.
mount -t nfs server:/folder /client -o vers=3,sec=krb5
1. On openSUSE 12.1
the mount is still nfs4 despite the -o vers=3
Fix: /etc/sysconfig/nfs needs to look like this:
USE_KERNEL_NFSD_NUMBER="4"
MOUNTD_PORT=""
NFS_SECURITY_GSS="yes"
###this next one is a real gotcha!###
NFS3_SERVER_SUPPORT="no"
NFS4_SUPPORT="no"
SM_NOTIFY_OPTIONS=""
NFS_START_SERVICES="yes"
STATD_OPTIONS=""
NFSV4LEASETIME=""
RPC_PIPEFS_DIR=""
SVCGSSD_OPTIONS=""
NFSD_OPTIONS=""
2. On Ubuntu, the -o vers=3 works with the same config as for nfs4:
/etc/default/nfs-common
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=yes
/etc/default/nfs-kernel-server
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=--manage-gids
NEED_SVCGSSD=yes
RPCSVCGSSDOPTS=
RPCNFSDOPTS=
Unfortunately (still Ubuntu) it only does small files. A 3Mb jpg freezes
us solid. But this must be Ubuntu (3.0.0-16-generic) as it's rock solid
on openSUSE. On nfs4 however, the jpg is sent fine. I'll
wireshark/syslog it 2moro.
We've documented it here:
http://linuxcostablanca.blogspot.com/2012/02/samba4-shares.html
So at last, the acl + appears on an nfs mount. But what a pity we have
had to fall back on nfs3.
Qns:
1. Do we need to remove /etc/idmapd.conf for nfs3?
2. Could I take this opportunity to ask as a feature request that
nfs4_setfacl be able to offer group rw from a 0022 umask?
We really appreciate the time you have given us. Please let us know if
there is anything we can do or test to help, acl or no acl.
Cheers,
Steve
On Wed, Feb 29, 2012 at 03:40:39PM +0100, steve wrote:
> On 02/29/2012 03:32 PM, J. Bruce Fields wrote:
> >On Wed, Feb 29, 2012 at 03:26:33PM +0100, steve wrote:
> >>On 02/29/2012 03:09 PM, J. Bruce Fields wrote:
> >>>On Wed, Feb 29, 2012 at 03:04:28PM +0100, steve wrote:
> >>>>On 29/02/12 13:44, J. Bruce Fields wrote:
> >>>>>On Wed, Feb 29, 2012 at 12:22:30AM +0100, steve wrote:
> >>>>>>We are authenticating against Samba4, so our domain user accounts
> >>>>>>are under Kerberos.
> >>>>>Kerberos works fine with v3.
> >>>>>
> >>>>>--b.
> >>>>Hi
> >>>>Unfortunately, it doesn't seem to. We just tried it, and anyone
> >>>>(with or without a ticket) gets access:-(
> >>>Could you give any more detail about your test?
> >>>
> >>>--b.
> >>steve is a /etc/passwd user
> >>
> >>steve@hh3:~$ sudo su
> >>[sudo] password for steve:
> >>root@hh3:/home/steve# mount -t nfs4 hh3:/home /mnt -o sec=krb5
> >>root@hh3:/home/steve# exit
> >>exit
> >>steve@hh3:~$ cd /mnt
> >>bash: cd: /mnt: Permission denied
> >>steve@hh3:~$ sudo su
> >>root@hh3:/home/steve# umount /mnt
> >>root@hh3:/home/steve# mount -t nfs hh3:/home /mnt -o sec=krb5
Careful: a recent client will negotiate v4 if you leave this
unspecified. You want -onfsversion=3,sec=krb5.
> >>root@hh3:/home/steve# exit
> >>exit
> >>steve@hh3:~$ cd /mnt
> >>steve@hh3:/mnt$
> >Why is that a problem? You haven't actually accessed anything on the
> >filesystem.
> >
> >--b.
> Steve can access the mounted folder. I can live with that but the
> acl still isn't working:
>
> lynn2 has authinticated by Kerberos
>
> root@hh3:~# setfacl -d -m g::rw /home/CACTUS/dropbox
> root@hh3:~# mount -t nfs hh3:/home /mnt -o sec=krb5
> lynn2@hh3:/mnt/CACTUS$ ls -la
> total 28
> drwxr-xr-x 6 root root 4096 2012-02-27 14:24 .
> drwxr-xr-x 4 root root 4096 2012-02-18 18:52 ..
> drwxrws--- 3 root debusers 4096 2012-02-29 15:31 dropbox
> drwxr-xr-x 20 lynn2 debusers 4096 2012-02-26 16:43 lynn2
> drwxrwxrwx 5 root root 4096 2012-02-29 14:19 profiles
> drwxr-xr-x 4 steve2 Domain Users 4096 2012-02-29 14:36 steve2
>
> lynn2 then crates a file in the mount called l3:
>
> lynn2@hh3:/mnt/CACTUS$ ls -la /home/CACTUS/dropbox/
> total 20
> drwxrws---+ 3 root debusers 4096 2012-02-29 15:31 .
> drwxr-xr-x 6 root root 4096 2012-02-27 14:24 ..
> -rw-r----- 1 lynn2 debusers 0 2012-02-29 15:31 a
> drwxrwS---+ 2 root debusers 4096 2012-02-29 14:28 adminfolder
> -rw-rw---- 1 lynn2 debusers 0 2012-02-25 23:23 l2
> -rw-r----- 1 lynn2 debusers 0 2012-02-29 15:24 l3
> -rw-rw---- 1 lynn2 debusers 0 2012-02-26 16:20 lynn2-ubuntu.txt
> -rw-rw---- 1 lynn2 debusers 11 2012-02-26 00:46 lynnnautilus.txt
>
> ??
I would have expected the default acl on the parent to override any
umask on v3.
So if it's actually v3, then that looks like a bug to me.
--b.
On Thu, Mar 01, 2012 at 11:11:24PM +0100, steve wrote:
> 1. Do we need to remove /etc/idmapd.conf for nfs3?
No.
> 2. Could I take this opportunity to ask as a feature request that
> nfs4_setfacl be able to offer group rw from a 0022 umask?
I agree that this needs to be fixed, but personally it's not likely to
make it to the top of my todo list very soon.
--b.