* Re: knfsd and append-only attribute: "operation not permitted"
[not found] <8381054C-6B13-11D9-BFA6-000D933B35AA@bdi.com>
@ 2005-01-21 14:44 ` Vladimir Saveliev
2005-01-21 15:53 ` Trond Myklebust
0 siblings, 1 reply; 4+ messages in thread
From: Vladimir Saveliev @ 2005-01-21 14:44 UTC (permalink / raw)
To: Aaron D.Ball; +Cc: reiserfs-list, linux-kernel@vger.kernel.org
Hello
On Thu, 2005-01-20 at 21:45, Aaron D.Ball wrote:
> When I use the kernel-based NFS server to export directories on
> ReiserFS that have the append-only attribute set, I can't access the
> files from the client machines at all: for example, "ls" returns
> "operation not permitted". Is this a known bug? Is there a good
> workaround?
>
It looks like the problem is not in reiserfs, but in nfsd.
fs/nfsd/vfs.c:nfsd_open() refuses to open append only files.
/* Disallow access to files with the append-only bit set or
* with mandatory locking enabled
*/
err = nfserr_perm;
if (IS_APPEND(inode) || IS_ISMNDLK(inode))
goto out;
> I'm running up-to-date Debian sid with Linux 2.6.10 compiled from the
> stock Debian kernel-source package. Everything works fine in other
> contexts, such as
>
> * direct access on the server
> * access via Samba
> * access via the userspace NFS server (which I'm using as a workaround
> for now)
>
> I'd really like to get things working with the kernel-based server so I
> can have locks. Abandoning extended attributes would mean I have to
> monitor certain files and directories for changes and check them after
> the fact rather than simply blocking all the changes I don't want. Is
> there hope? Am I just doing something dumb?
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: knfsd and append-only attribute: "operation not permitted"
2005-01-21 14:44 ` knfsd and append-only attribute: "operation not permitted" Vladimir Saveliev
@ 2005-01-21 15:53 ` Trond Myklebust
2005-01-21 16:23 ` Aaron D. Ball
0 siblings, 1 reply; 4+ messages in thread
From: Trond Myklebust @ 2005-01-21 15:53 UTC (permalink / raw)
To: Vladimir Saveliev
Cc: Aaron D.Ball, reiserfs-list, linux-kernel@vger.kernel.org
fr den 21.01.2005 Klokka 17:44 (+0300) skreiv Vladimir Saveliev:
> Hello
>
> On Thu, 2005-01-20 at 21:45, Aaron D.Ball wrote:
> > When I use the kernel-based NFS server to export directories on
> > ReiserFS that have the append-only attribute set, I can't access the
> > files from the client machines at all: for example, "ls" returns
> > "operation not permitted". Is this a known bug? Is there a good
> > workaround?
> >
>
> It looks like the problem is not in reiserfs, but in nfsd.
> fs/nfsd/vfs.c:nfsd_open() refuses to open append only files.
Append-only is an unsupported concept in the all existing revisions of
the NFS protocol. In fact, NFS has no support for append writes at all:
they have to be emulated by the clients.
Cheers,
Trond
--
Trond Myklebust <trond.myklebust@fys.uio.no>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: knfsd and append-only attribute: "operation not permitted"
2005-01-21 15:53 ` Trond Myklebust
@ 2005-01-21 16:23 ` Aaron D. Ball
2005-01-21 17:08 ` Trond Myklebust
0 siblings, 1 reply; 4+ messages in thread
From: Aaron D. Ball @ 2005-01-21 16:23 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Vladimir Saveliev, linux-kernel@vger.kernel.org
Trond Myklebust wrote:
>fr den 21.01.2005 Klokka 17:44 (+0300) skreiv Vladimir Saveliev:
>
>
>> fs/nfsd/vfs.c:nfsd_open() refuses to open append only files.
>
>
>Append-only is an unsupported concept in the all existing revisions of
>the NFS protocol. In fact, NFS has no support for append writes at all:
>they have to be emulated by the clients.
>
>
OK, but that certainly shouldn't preclude read access. The way it is
now, you can't even list append-only directories. It seems like this
check should treat append-only files as read-only, only failing to open
them if write access is requested, rather than failing all the time like
it does now.
In this particular case, I'm not using append-only files, but rather
using immutable files and append-only directories to create an archival
space where things can be added but not changed. Even if the protocol
can't deal with append-only regular files, isn't it possible to allow
mkdir but not rmdir?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: knfsd and append-only attribute: "operation not permitted"
2005-01-21 16:23 ` Aaron D. Ball
@ 2005-01-21 17:08 ` Trond Myklebust
0 siblings, 0 replies; 4+ messages in thread
From: Trond Myklebust @ 2005-01-21 17:08 UTC (permalink / raw)
To: Aaron D. Ball; +Cc: Vladimir Saveliev, linux-kernel@vger.kernel.org
fr den 21.01.2005 Klokka 11:23 (-0500) skreiv Aaron D. Ball:
> OK, but that certainly shouldn't preclude read access. The way it is
> now, you can't even list append-only directories. It seems like this
> check should treat append-only files as read-only, only failing to open
> them if write access is requested, rather than failing all the time like
> it does now.
Agreed.
> In this particular case, I'm not using append-only files, but rather
> using immutable files and append-only directories to create an archival
> space where things can be added but not changed. Even if the protocol
> can't deal with append-only regular files, isn't it possible to allow
> mkdir but not rmdir?
Append-only directories should be no problem as far as the protocol
goes, and neither should immutable files.
I suggest you take this bug to the NFS mailing list
nfs@lists.sourceforge.net or talk directly to the knfsd maintainer Neil
Brown (neilb@cse.unsw.edu.au).
Cheers,
Trond
--
Trond Myklebust <trond.myklebust@fys.uio.no>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-01-21 17:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <8381054C-6B13-11D9-BFA6-000D933B35AA@bdi.com>
2005-01-21 14:44 ` knfsd and append-only attribute: "operation not permitted" Vladimir Saveliev
2005-01-21 15:53 ` Trond Myklebust
2005-01-21 16:23 ` Aaron D. Ball
2005-01-21 17:08 ` Trond Myklebust
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox