* 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