Red Hat Bugzilla – Bug 807439
NFS snapshot directory issues with 2.6.18-308.el5
Last modified: 2012-05-09 10:05:33 EDT
Description of problem:
When running the new 5.8 kernel 2.6.18-308.el5 we can no longer get into special copy on write snapshot directories over NFS.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run 2.6.18-308.el5 on RHEL5
2. Mount a ZFS file system over NFS (v3) to /mnt
3. cd /mnt/.zfs/snapshot/<name_of_snapshot>
You will get something like, 'snap-hourly-4-latest/: Not a directory'
Change directory would work as expected into the snapshot.
Downgrading to kernel 2.6.18-274.18.1.el5 or earlier fixes the issue.
We don't support ZFS in production in any system.
I suggest trying more recent versions of RHEL to see if this was resolved for you.
Specifically is a regression in the NFS _client_ in 2.6.18-308.el5. I can confirm this behavior also using RHEL5 2.6.18-308.el5 client to access a ONStor NFS file share with a .snapshot directory. This behavior is not ZFS related but it is an easy way to reproduce the problem. RHEL6 does not exhibit this behavior (2.6.32-220.7.1.el6).
I also see that on 2.6.18-308.1.1.el5 (mounting zfs from solaris 10 server), it used to work for the 5.7 kernel series.
If either of you have a Red Hat support account, please open a support call officially so the field can collect more information.
Opening a ticket directly in our bugzilla bypasses the support team who could work with you to find a supported test case that shows an issue.
Other than that, you can take this issue to the upstream NFS list or to the other vendor (Oracle for Solaris).
Could this be related to BUGID 798809?
@Derek: Are you using NFSv4?
I am using nfsv3 and the issue does NOT occur on Hitachi HNAS (was bluearc) served snapshots.
This issue DOES occur with NetApp (NFSv3), but only if the volume is root-exported (equivalent to no_root_squash). For volumes not exported with root privileges this is not an issue. Is it the same for the other storage solutions mentioned?
(In reply to comment #7)
> For volumes not exported *with* root privileges this is not an issue.
For volumes not exported *without* root privileges this is not an issue.
Sorry about that.
(In reply to comment #8)
> (In reply to comment #7)
> > For volumes not exported *with* root privileges this is not an issue.
> For volumes not exported *without* root privileges this is not an issue.
This is ridiculous.. I actually got it right in the first place.
For those of you with Solaris/ZFS and other storage solutions, please confirm if the issue occurs with and/or without no_root_squash.
My testing shows that under ZFS the defect is still apparent with or without no_root_squash exportation from the server.
Please do open a proper support ticket for this issue, the Red Hat support team is quite good at gathering data and helping debug.
Updating this bugzilla is not a replacement for proper support escalations.
I would hope that Red Hat would like to continue to have its paying customers that do not have the ability to log support cases to let Red Hat know about bugs within their products.
I just want to update this to say that RHSA-2012:0480-01 fixes the issues described here in the product which includes bug 801726.
So the regression was not exclusive to NFSv4 but also NFSv3. I have marked this bug as a duplicate of 801726.
*** This bug has been marked as a duplicate of bug 801726 ***
Hi Derek - thanks for reporting this. I've marked it a dup as you said in comment #13. And yes of course, we always want to hear about bugs.
Can you log into the portal (http://access.redhat.com) and search our kbase?
If so, you can often find common issues like this one documented. Here's the article which documents this problem: