| To: | xfs@xxxxxxxxxxx, James Braid <jamesb@xxxxxxxxxxxx> |
|---|---|
| Subject: | Re: New CentOS4/RHEL4-compatible xfs module rpms |
| From: | James Pearson <james-p@xxxxxxxxxxxxxxxxxx> |
| Date: | Wed, 08 Aug 2007 17:04:29 +0100 |
| Cc: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040524 |
That's odd. You have the module on the server, exporting an xfs filesystem, and you're getting permission denied on the client? The 'stock' RHEL4/CentOS4 kernels don't have xfs modules - so, I guess you have rebuilt your kernel with the XFS code that is there by default? If this is the case, then this _may be_ the cause of the problem ... the updated xfs module code uses any existing XFS configs in the kernel you are building against - the Makefile states: # Set up our config. # # If the kernel already has an XFS config, use it. # Else if config.xfs is here, use it for our config. Otherwise, # Else default to only CONFIG_XFS_FS=m (simplest config) The problem is that the 'stock' 2.6.9 kernel doesn't define (or use) CONFIG_XFS_EXPORT - but the updated xfs module code requires this to allow NFS exports of a XFS file system ... So my guess is that your re-built updated xfs modules don't use CONFIG_XFS_EXPORT I guess with a bit of hacking to the Makefile, you could force 'CONFIG_XFS_EXPORT=y' to be added - you might even be able to do this via the rpmbuild command line ... although I don't know how. James Pearson |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: New CentOS4/RHEL4-compatible xfs module rpms, Eric Sandeen |
|---|---|
| Next by Date: | Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND), Andrew Morton |
| Previous by Thread: | Impact of atime updates on XFS, Martin Steigerwald |
| Next by Thread: | Re: New CentOS4/RHEL4-compatible xfs module rpms, Eric Sandeen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |