On Fri, Jun 6, 2014 at 3:29 PM, Philippe Troin <phil@xxxxxxxxxxxxxxxxx> wrote: > This happens on an NFS client running on: > Linux ceramic32 3.14.4 #1 SMP Fri May 30 00:52:07 PDT 2014 i686 i686 i386 GNU/Linux > (also happens on x86_64). > > The NFS server can be either 3.14 or 3.13, it doesn't change a thing. > > Mount options are: > (from /proc/mtab) > ceramic:/export/home/phil /home/phil nfs rw,nosuid,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.17.1.2,mountvers=3,mountport=20048,mountproto=tcp,local_lock=none,addr=172.17.1.2 0 0 > (This is NFSv3) > > The symptom: > > Run getfacl on any NFS inode. See there are no ACLs: > > % getfacl . > # file: . > # owner: phil > # group: phil > user::rwx > group::r-x > other::r-x > > Yet, getfattr says there are some acl-related xattrs: > > % getfattr -m '.*' . > # file: . > system.posix_acl_access > system.posix_acl_default > > But when you want to retrieve these phantom xattrs, I get errors: > > % getfattr -n system.posix_acl_access . > .: system.posix_acl_access: No such attribute > [1] 1136 exit 1 getfattr -n system.posix_acl_access . > % getfattr -n system.posix_acl_default . > .: system.posix_acl_default: No such attribute > [1] 1146 exit 1 getfattr -n system.posix_acl_default . > > I've noticed because it breaks the patch utility. > > This is a regression from 3.13, probably due to the 3.14 NFS ACL overhaul. > Christoph, what is the intended interface for telling posix_acl_xattr_list() that there are no acls on a particular file? Should there perhaps be a call to get_acl()? -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
