On 9/4/23 4:50 AM, James Youngman wrote:
---
utils/mount/nfs.man | 1 -
1 file changed, 1 deletion(-)
Committed...
steved.
diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index 7a410422..c9850f29 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -986,7 +986,6 @@ file
On 12/05/2011 01:42 PM, Anibal Monsalve Salazar wrote:
> On Mon, Dec 05, 2011 at 10:52:18AM -0500, Steve Dickson wrote:
>> Why not just use the --with-pluginpath configuration flag?
>> That's how we do it in Fedora...
>
> The --with-pluginpath configuration option
Hello,
On 12/05/2011 03:25 AM, Anibal Monsalve Salazar wrote:
> Hello Steve and Kevin,
>
> To fix Debian Bug#649491[1], I moved the .so files to /lib and applied
> the following patch:
>
> --- a/libnfsidmap.c 2010-12-09 04:07:53.0 +1100
> +++ b/libnfsidmap.c 2011-12-05 11:23:46.
Chuck Lever wrote:
So where have I gone wrong in reproducing this?
>>>
>>> What happens when you don't specify a sec= option at all?
>>
>> 'touch /mnt/home/tmp/foo && rm /mnt/home/tmp/foo' works as expected...
>
> I'm out of ideas then.
Me too... :(
>
> The problem was with the mount comman
Chuck Lever wrote:
>> Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an
>> FC-7 (2.6.21) kernel. New text mount interface with old binary kernel
>> interface.
>>
>> I have two servers:
>> ServerA has the nfs-utils-1.1.3 rpc.mountd binary using an F-9
>> 2.6.26 kernel
>> Serve
Chuck Lever wrote:
>>> Easy... the mount.nfs subcommand in nfs-utils-1.1.3 switches to legacy
>>> mode on old kernels (pre 2.6.23). What I meant by "you need to force
>>> the use of the legacy mount command" is that you need to force the use
>>> of the legacy binary mount interface.
>> I have trie
Chuck Lever wrote:
> On Oct 9, 2008, at Oct 9, 2008, 11:48 AM, Steve Dickson wrote:
>> Unfortunately, I'm failing miserably on reproducing this... Here is
>> what I've done:
>>
>> Chuck Lever wrote:
>>> Hi Steve-
>>>
>>> As I und
> (BTW, I had a look at the sourceforge mailing list for NFS-utils and it seems
> to be 100% spam. Is there a better upstream bug reporting channel?)
The new upstream mailing list is [EMAIL PROTECTED] and upstream bug database is
at https://bugzilla.linux-nfs.org... posting things there will ge
Unfortunately, I'm failing miserably on reproducing this... Here is what I've
done:
Chuck Lever wrote:
> Hi Steve-
>
> As I understand it, the documented bug refers to running nfs-utils 1.1.3
> on kernels older than 2.6.22.
I created a Fedora 7 KVM guest that runs a 2.6.21 kernel. I installed t
Aníbal Monsalve Salazar wrote:
> On Sat, Jun 07, 2008 at 01:53:02AM +, Richard A Nelson wrote:
>> Package: nfs-common
>> Version: 1:1.1.2-4
>> Severity: important
>>
>> In a fit of debugging spurious NFS problems I noticed this:
>>
>> # ps auxw | grep statd
>> statd 4136 0.0 0.0 2056
What is logged in /var/log/messages you turn on the in-kernel mount debugging
via:
rpcdebug -m nfs -s mount
then do the following three mounts:
mount -o sec=none madhat:/home /mnt/home
mount -o sec=sys madhat:/home /mnt/home
mount madhat:/home /mnt/home
I got:
Oct 2 09:23:10 rawhat kernel:
Aníbal Monsalve Salazar wrote:
>> In my case I run Debian stable (nfs-utils 1.0.10) on the server and
>> Debian unstable (1.1.3) on the client.
>>
>> I have not tried upgrading the server (which is probably not an option
>> until Debian Lenny is released), but running the client with sec=sys
>> s
Kevin Coffman wrote:
>> --- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200
>> +++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200
>> @@ -101,7 +101,7 @@
>>char plgname[128];
>>int ret = 0;
>>
>> - snprintf(plgname, sizeof(plgnam
13 matches
Mail list logo
