We have a Slackware 9.1 box (with numerous software upgrades) exporting a
directory to various NFS clients. While running a 2.4.x kernel this all
worked fine - users on clients could use "quota" to display their quota
information. When the system was moved to a 2.6.19.2 kernel a few months
ago the clients could no longer display quota information. The server
still knew and enforced the quotas, it's just that from the client's
point of view there were no quotas.
The system is running the following software versions:
* kernel 2.6.19.2
* nfs-utils 1.0.10
* util-linux 2.12
* portmap 5.0
The filesystem concerned is reiserfs3. The kernel has reiserfs quota
support enabled.
The relevant partition is mounted on the server using an fstab entry of
/dev/... /home/foobar reiserfs usrquota
All clients mount the volume via the automounter with the "hard,intr,bg"
mount options.
Users cannot log into the NFS server.
We have clients running various versions of redhat, fedora and slackware
with different kernels. In all cases things worked with the 2.4.x
kernel and don't now. It therefore seems to be a server-related issue.
Does anyone have any idea as to why client access to quota information
isn't working in this scenario?
Regards
jonathan
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 2007-05-03 at 11:43 +0930, Jonathan Woithe wrote:
> We have a Slackware 9.1 box (with numerous software upgrades) exporting a
> directory to various NFS clients. While running a 2.4.x kernel this all
> worked fine - users on clients could use "quota" to display their quota
> information. When the system was moved to a 2.6.19.2 kernel a few months
> ago the clients could no longer display quota information. The server
> still knew and enforced the quotas, it's just that from the client's
> point of view there were no quotas.
>
> The system is running the following software versions:
>
> * kernel 2.6.19.2
> * nfs-utils 1.0.10
> * util-linux 2.12
> * portmap 5.0
>
> The filesystem concerned is reiserfs3. The kernel has reiserfs quota
> support enabled.
>
> The relevant partition is mounted on the server using an fstab entry of
>
> /dev/... /home/foobar reiserfs usrquota
>
> All clients mount the volume via the automounter with the "hard,intr,bg"
> mount options.
>
> Users cannot log into the NFS server.
>
> We have clients running various versions of redhat, fedora and slackware
> with different kernels. In all cases things worked with the 2.4.x
> kernel and don't now. It therefore seems to be a server-related issue.
>
> Does anyone have any idea as to why client access to quota information
> isn't working in this scenario?
The NFS protocol doesn't support quotas, so those have to be transmitted
using a sideband protocol. Check that you have the 'quotad' daemon
running on your server, and that it is accessible from the clients.
Trond
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> On Thu, 2007-05-03 at 11:43 +0930, Jonathan Woithe wrote:
> > We have a Slackware 9.1 box (with numerous software upgrades) exporting a
> > directory to various NFS clients. While running a 2.4.x kernel this all
> > worked fine - users on clients could use "quota" to display their quota
> > information. When the system was moved to a 2.6.19.2 kernel a few months
> > ago the clients could no longer display quota information. The server
> > still knew and enforced the quotas, it's just that from the client's
> > point of view there were no quotas.
> >
> > The system is running the following software versions:
> >
> > * kernel 2.6.19.2
> > * nfs-utils 1.0.10
> > * util-linux 2.12
> > * portmap 5.0
> >
> > The filesystem concerned is reiserfs3. The kernel has reiserfs quota
> > support enabled.
> >
> > The relevant partition is mounted on the server using an fstab entry of
> >
> > /dev/... /home/foobar reiserfs usrquota
> >
> > All clients mount the volume via the automounter with the "hard,intr,bg"
> > mount options.
> >
> > Users cannot log into the NFS server.
> >
> > We have clients running various versions of redhat, fedora and slackware
> > with different kernels. In all cases things worked with the 2.4.x
> > kernel and don't now. It therefore seems to be a server-related issue.
> >
> > Does anyone have any idea as to why client access to quota information
> > isn't working in this scenario?
>
> The NFS protocol doesn't support quotas, so those have to be transmitted
> using a sideband protocol. Check that you have the 'quotad' daemon
> running on your server, and that it is accessible from the clients.
Yes, quotad is running on the server:
> rpcinfo -p
:
100011 1 udp 998 rquotad
100011 2 udp 998 rquotad
As I mentioned, everything works just fine if a 2.4.x kernel is running,
which presumedly clears any access issues (unless of course the 2.6.x kernel
is doing something odd). The moment 2.6.x is booted (where x = 19.2
currently) the clients can no longer see quota information.
Is there a way to explicitly test whether clients can in fact connect to
rquotad?
I have noticed that rquotad is only listening on UDP, rather than on both
TCP and UDP as I think it did under 2.4.x. Is this likely to be the
problem? If so, what would cause rquotad to do this under 2.6.x given an
unchanged configuration from 2.4.x?
Here are the relevant kernel configuration options for the kernel currently
running:
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
Regards
jonathan
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-05-07 at 08:57 +0930, Jonathan Woithe wrote:
> > On Thu, 2007-05-03 at 11:43 +0930, Jonathan Woithe wrote:
> > > We have a Slackware 9.1 box (with numerous software upgrades) exporting a
> > > directory to various NFS clients. While running a 2.4.x kernel this all
> > > worked fine - users on clients could use "quota" to display their quota
> > > information. When the system was moved to a 2.6.19.2 kernel a few months
> > > ago the clients could no longer display quota information. The server
> > > still knew and enforced the quotas, it's just that from the client's
> > > point of view there were no quotas.
> > >
> > > The system is running the following software versions:
> > >
> > > * kernel 2.6.19.2
> > > * nfs-utils 1.0.10
> > > * util-linux 2.12
> > > * portmap 5.0
> > >
> > > The filesystem concerned is reiserfs3. The kernel has reiserfs quota
> > > support enabled.
> > >
> > > The relevant partition is mounted on the server using an fstab entry of
> > >
> > > /dev/... /home/foobar reiserfs usrquota
> > >
> > > All clients mount the volume via the automounter with the "hard,intr,bg"
> > > mount options.
> > >
> > > Users cannot log into the NFS server.
> > >
> > > We have clients running various versions of redhat, fedora and slackware
> > > with different kernels. In all cases things worked with the 2.4.x
> > > kernel and don't now. It therefore seems to be a server-related issue.
> > >
> > > Does anyone have any idea as to why client access to quota information
> > > isn't working in this scenario?
> >
> > The NFS protocol doesn't support quotas, so those have to be transmitted
> > using a sideband protocol. Check that you have the 'quotad' daemon
> > running on your server, and that it is accessible from the clients.
>
> Yes, quotad is running on the server:
>
> > rpcinfo -p
> :
> 100011 1 udp 998 rquotad
> 100011 2 udp 998 rquotad
>
> As I mentioned, everything works just fine if a 2.4.x kernel is running,
> which presumedly clears any access issues (unless of course the 2.6.x kernel
> is doing something odd). The moment 2.6.x is booted (where x = 19.2
> currently) the clients can no longer see quota information.
>
> Is there a way to explicitly test whether clients can in fact connect to
> rquotad?
>
> I have noticed that rquotad is only listening on UDP, rather than on both
> TCP and UDP as I think it did under 2.4.x. Is this likely to be the
> problem? If so, what would cause rquotad to do this under 2.6.x given an
> unchanged configuration from 2.4.x?
>
> Here are the relevant kernel configuration options for the kernel currently
> running:
On the client, the kernel isn't at all involved in NFS quotas other than
for the usual sendmsg()/recvmsg() syscalls as used by the userspace RPC
library. IOW: all the clever stuff happens in userspace.
I'd therefore try running 'strace' on the 'quota' command in order to
figure out what is going wrong.
Trond
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> On Mon, 2007-05-07 at 08:57 +0930, Jonathan Woithe wrote:
> > > On Thu, 2007-05-03 at 11:43 +0930, Jonathan Woithe wrote:
> > > > We have a Slackware 9.1 box (with numerous software upgrades) exporting a
> > > > directory to various NFS clients. While running a 2.4.x kernel this all
> > > > worked fine - users on clients could use "quota" to display their quota
> > > > information. When the system was moved to a 2.6.19.2 kernel a few months
> > > > ago the clients could no longer display quota information. The server
> > > > still knew and enforced the quotas, it's just that from the client's
> > > > point of view there were no quotas.
> > > >
> > > > The system is running the following software versions:
> > > >
> > > > * kernel 2.6.19.2
> > > > * nfs-utils 1.0.10
> > > > * util-linux 2.12
> > > > * portmap 5.0
> > > >
> > > > The filesystem concerned is reiserfs3. The kernel has reiserfs quota
> > > > support enabled.
> > > >
> > > > The relevant partition is mounted on the server using an fstab entry of
> > > >
> > > > /dev/... /home/foobar reiserfs usrquota
> > > >
> > > > All clients mount the volume via the automounter with the "hard,intr,bg"
> > > > mount options.
> > > >
> > > > Users cannot log into the NFS server.
> > > >
> > > > We have clients running various versions of redhat, fedora and slackware
> > > > with different kernels. In all cases things worked with the 2.4.x
> > > > kernel and don't now. It therefore seems to be a server-related issue.
> > > >
> > > > Does anyone have any idea as to why client access to quota information
> > > > isn't working in this scenario?
> > >
> > > The NFS protocol doesn't support quotas, so those have to be transmitted
> > > using a sideband protocol. Check that you have the 'quotad' daemon
> > > running on your server, and that it is accessible from the clients.
> >
> > Yes, quotad is running on the server:
> >
> > > rpcinfo -p
> > :
> > 100011 1 udp 998 rquotad
> > 100011 2 udp 998 rquotad
> >
> > As I mentioned, everything works just fine if a 2.4.x kernel is running,
> > which presumedly clears any access issues (unless of course the 2.6.x kernel
> > is doing something odd). The moment 2.6.x is booted (where x = 19.2
> > currently) the clients can no longer see quota information.
> >
> > Is there a way to explicitly test whether clients can in fact connect to
> > rquotad?
> >
> > I have noticed that rquotad is only listening on UDP, rather than on both
> > TCP and UDP as I think it did under 2.4.x. Is this likely to be the
> > problem? If so, what would cause rquotad to do this under 2.6.x given an
> > unchanged configuration from 2.4.x?
> >
> > Here are the relevant kernel configuration options for the kernel currently
> > running:
>
> On the client, the kernel isn't at all involved in NFS quotas other than
> for the usual sendmsg()/recvmsg() syscalls as used by the userspace RPC
> library. IOW: all the clever stuff happens in userspace.
>
> I'd therefore try running 'strace' on the 'quota' command in order to
> figure out what is going wrong.
I tried that earlier but nothing really jumped out at me - it seemed that
the server was being contacted without error.
If you're interested you can download a copy of the strace output from
a representative client from
http://www.physics.adelaide.edu.au/~jwoithe/q-mercury.strace.bz2
I would have attached it but I suspect it might make the message too big
for the list.
In the meantime I might try comparing the strace from the client (where it
doesn't work) and the server (where it does) and see if anything obvious
jumps out.
Regards
jonathan
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thursday May 3, [email protected] wrote:
> We have a Slackware 9.1 box (with numerous software upgrades) exporting a
> directory to various NFS clients. While running a 2.4.x kernel this all
> worked fine - users on clients could use "quota" to display their quota
> information. When the system was moved to a 2.6.19.2 kernel a few months
> ago the clients could no longer display quota information. The server
> still knew and enforced the quotas, it's just that from the client's
> point of view there were no quotas.
>
> The system is running the following software versions:
>
> * kernel 2.6.19.2
> * nfs-utils 1.0.10
> * util-linux 2.12
> * portmap 5.0
>
> The filesystem concerned is reiserfs3. The kernel has reiserfs quota
> support enabled.
Hmm... what "rquotad" is running? It appears that both the "quota"
package and the "nfs-utils" package contains "rquotad". And the one
in nfs-utils is fairly thoroughly broken (only recognises ext2 and
ext3 for a start).
You can tell which you are using by running it with "-v".
e.g.
/usr/sbin/rpc.rquotad -v
The "nfs-utils" one will say
rquotad 1.0.10
The "quota" one will give a "Usage" message because it doesn't
understand -v.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> On Thursday May 3, jwoithe wrote:
> > We have a Slackware 9.1 box (with numerous software upgrades) exporting a
> > directory to various NFS clients. While running a 2.4.x kernel this all
> > worked fine - users on clients could use "quota" to display their quota
> > information. When the system was moved to a 2.6.19.2 kernel a few months
> > ago the clients could no longer display quota information. The server
> > still knew and enforced the quotas, it's just that from the client's
> > point of view there were no quotas.
> >
> > The system is running the following software versions:
> >
> > * kernel 2.6.19.2
> > * nfs-utils 1.0.10
> > * util-linux 2.12
> > * portmap 5.0
> >
> > The filesystem concerned is reiserfs3. The kernel has reiserfs quota
> > support enabled.
>
> Hmm... what "rquotad" is running? It appears that both the "quota"
> package and the "nfs-utils" package contains "rquotad". And the one
> in nfs-utils is fairly thoroughly broken (only recognises ext2 and
> ext3 for a start).
>
> You can tell which you are using by running it with "-v".
> e.g.
> /usr/sbin/rpc.rquotad -v
>
> The "nfs-utils" one will say
> rquotad 1.0.10
> The "quota" one will give a "Usage" message because it doesn't
> understand -v.
Well spotted Neil. The server was in fact running the rquotad from
nfs-utils 1.0.10. Originally (like most other distributions) the system was
running the "quota package" version, but when I upgraded nfs-utils at some
point for some reason nfs-utils seems to have silently replaced rpc.rquotad
with its own apparently broken version. After restoring the original "quota
package" rpc.rquotad the clients can once again view quota information.
Thanks everyone for your assistance with this one.
Regards
jonathan
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs