I'm asking here before reporting it to TUV just in case I'm doing something really stupid. Just for some variety we just discovered a different NFS problem with the new SL5 kernels - with the NFS server stuff this time. Having upgraded a box to 2.6.18-53.1.4.el5 (either x86 or x86_64), older Linux boxes (e.g. SL3 boxes running 2.4.21-53.EL) mounting from the server start reporting 'EIO' errors when they tries to get some kinds of info. e.g. $ mkdir /mnt/testing $ mount zex:/local/scratch/ /mnt/testing/ $ ls -al /mnt/testing/public/test ls: /mnt/testing/public/test: Input/output error -rw-r--r-- 1 jp107 other 367 Dec 18 16:24 /mnt/testing/public/test After some tracking down (based on the logs on the server and tracing the traffic) it seems that this is a problem with the nfs acl code and mounting noacl fixes it (at least that is a short term fix)... $ umount /mnt/testing/ $ mount -o noacl zex:/local/scratch/ /mnt/testing/ $ ls -al /mnt/testing/public/test -rw-r--r-- 1 jp107 other 367 Dec 18 16:24 /mnt/testing/public/test Not that we use acls much but this regression seems wrong. Now it seems NOT to affect clients running newer (2.6) kernels so SL4/SL5 clients are not affected by this - though it might just be silently falling back to not supporting ACLs on there... I found a brief thread discussing what seems to be the same underlying problem (with 2.6.19 kernels) on the kernel mailing list from back in January: http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-01/msg03478.html I'm currently building a kernel with the suggested patch (from Neil Brown) to check if that fixes it. Without that patch it seems to not fill in the nfsd_acl_versions[vers] fields so probably doesn't handle ACLs at all as far as I can follow. Does anyone else see this behaviour (or are we the only ones left using NFS from such old systems)? -- Jon Peatfield, Computer Officer, DAMTP, University of Cambridge Mail: [log in to unmask] Web: http://www.damtp.cam.ac.uk/