On Aug 20, Michael Stone wrote:
> This should probably actually be in the rpcbind package rather than
> nfs-common. Once upon a time, when rpcbind was still portmap, it was
> actually part of netbase so a dependency was unnecessary. But rpcinfo is
And after my slimming cure nowadays n
(cc'ing package maintainers for insight)
On Mon, Aug 20, 2018 at 11:07:13PM +0200, Grzegorz Sójka wrote:
Please add netbase to the deps of the nfs-common package. Without it
mounting is impossible, more details may be found in the "Sid: NFSv3
mounting problem" thread.
This
On 08/20/18 23:12, Greg Wooledge wrote:
On Mon, Aug 20, 2018 at 11:07:13PM +0200, Grzegorz Sójka wrote:
Hi there,
Please add netbase to the deps of the nfs-common package. Without it
mounting is impossible, more details may be found in the "Sid: NFSv3
mounting problem" thre
On Mon, Aug 20, 2018 at 11:07:13PM +0200, Grzegorz Sójka wrote:
> Hi there,
>
> Please add netbase to the deps of the nfs-common package. Without it
> mounting is impossible, more details may be found in the "Sid: NFSv3
> mounting problem" thread.
http://bugs.debian.org
Hi there,
Please add netbase to the deps of the nfs-common package. Without it
mounting is impossible, more details may be found in the "Sid: NFSv3
mounting problem" thread.
--
Pozdrawiam
Grzesiek
Wysłane z kompa wolnego od wirusów Billa Gatesa.
Hello Debian Team !
I have three NFSv4 server on my network, all Debian Jessie recently
upgraded to Stretch.
Usually on Jessie, two services are running on NFS servers :
-> nfs-common that is used for both nfs clients and server
-> nfs-kernel-server that is used only by the server
But sin
No I'm using 2.6.26 kernel.
As to the bug report it mentioned version 1:1.2.1-1 of nfs-common. The version
on my machine is 1:1.1.2-6I .So the workaround 'Rolling back to version
1:1.2.0-4.1' could not be applied.
t; register (statd,1,udp) . I found some information about a bug in
> nfs-common that results in this kind of failure but the posts were
> from 2008 and the bug should have been fixed by now. Any ideas?
Just in case... Are you using a newer than Lenny Linux kernel? If so
then you will h
t the server fails to start. The message in
> syslog is 'rpc.statd[2400]: unable to register (statd,1,udp) . I found
> some information about a bug in nfs-common that results in this kind of
> failure but the posts were from 2008 and the bug should have been fixed
> by now. Any ideas?
Y
some information about a bug in
nfs-common that results in this kind of failure but the posts were from 2008
and the bug should have been fixed by now. Any ideas?
On Thu, Feb 10, 2011 at 1:47 PM, Mario Kleinsasser
wrote:
>>
>> Are you sure that Lenny's using nfsv4?
>
> Yes, I am sure because of this two points (Lenny):
> First:
> 08:30 root@xx:/mnt# mount -v -t nfs4
> xxx.xxx.xxx.xxx:/home/USERNAME /mnt/test
> mount.nfs4: pinging: prog 13 ve
>
>
> You're welcome.
>
> Are you sure that Lenny's using nfsv4?
>
>
>
Yes, I am sure because of this two points (Lenny):
First:
08:30 root@xx:/mnt# mount -v -t nfs4
xxx.xxx.xxx.xxx:/home/USERNAME /mnt/test
mount.nfs4: pinging: prog 13 vers 4 prot tcp port 2049
xxx.xxx.xxx.xxx:/hom
e
>> > bug #585085.
>> > My question: is anyone using Lenny and Squeeze as NFS v4 only client in
>> > parallel? I have not installed a "normal" NFSv4 server until know I
>> > hope
>> > anyone could give me a hint to solve this.
>> > F
e a VMWare Esxi environment so its easy to test the
>> > behavior. When I shutdown the Squeeze box and startup the Lenny box
>> (same IP
>> > etc...), all is working without problems. The other way - no chance. I
>> also
>> > read about some problems in the Debian b
down the Squeeze box and startup the Lenny box (same
> IP
> > etc...), all is working without problems. The other way - no chance. I
> also
> > read about some problems in the Debian bug tracker and a common
> workaround
> > for some problems is to downgrade to the Lenny v
way - no chance. I also
> read about some problems in the Debian bug tracker and a common workaround
> for some problems is to downgrade to the Lenny version of nfs-common, like
> bug #585085.
> My question: is anyone using Lenny and Squeeze as NFS v4 only client in
> parallel? I have
e Lenny version of nfs-common, like
bug #585085.
My question: is anyone using Lenny and Squeeze as NFS v4 only client in
parallel? I have not installed a "normal" NFSv4 server until know I hope
anyone could give me a hint to solve this.
For your information, both servers, Lenny and S
on 03:33 Fri 04 Feb, T o n g (mlist4sunt...@yahoo.com) wrote:
> On Thu, 03 Feb 2011 14:04:52 -0800, Dr. Ed Morbius wrote:
>
> >> How do I fix this problem?
> >>
> >> % invoke-rc.d nfs-common start
> >> Starting NFS common utilities: statd failed! invok
on 20:50 Thu 03 Feb, T o n g (mlist4sunt...@yahoo.com) wrote:
>
> Hi,
>
> How do I fix this problem?
>
> % invoke-rc.d nfs-common start
> Starting NFS common utilities: statd failed!
> invoke-rc.d: initscript nfs-common, action "start" failed.
>
> Ap
Hi,
It seems that latest nfs-common is broken on sid. After installing
1:1.1.2-1 yesterday my NAS drive didn't mount back after restarting my
desktop PC (which I turn it off at night). Timeouts occurred. I restored
the previous nfs-common, which is 1:1.1.1-14 and it works again.
I rep
The configure command in the postinstall script on the latest version of
nfs-common is broken. I don't have anything using nfs so my solution was
to do apt-get remove nfs-common.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble?
I have found one of your mail in debian-user archived here :
http://lists.debian.org/debian-user/2005/05/msg03518.html
It was about bug 165744 in nfs-common. Unfortuntaley (nfs-common 1.0.7)
did not reached sarge.
Did you get a reply or solution to this nfs-common problem ?
Friendly,
--
Dr
Hi there,
Package nfs-common in sarge is still at upstream version 1.0.6, which
has the "Received erroneous SM_UNMON request" bug (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=165744&archive=yes).
In essence, the bug is that when a nfs server receives a request to
"
Thomas Adam said:
> Why don't you run it, and see?
duh, just needed the -m switch, did a
man start-stop-deamon and finally saw the -m switch.
I'm configuring all my service to be monitored by monit.
--
--Luke CS Sysadmin, Montana State University-Bozeman
--
To UNSUBSCRIBE, email to [EMAIL PR
--- Lucas Albers <[EMAIL PROTECTED]> wrote:
> Does this syntax look correct, I just need to add in a --pidfie to
> start-stop-deamon to have a pidfile written for the process, correct?
> Assuming I have defined LOCKDPID and STATDPID.
Why don't you run it, and see?
-- Thomas Adam
=
"The Li
I am running nfs-common from woody.
I was trying to modify the /etc/init.d/nfs-common script to write the pid
file of statd/lockd on startup.
Does this syntax look correct, I just need to add in a --pidfie to
start-stop-deamon to have a pidfile written for the process, correct?
Assuming I have
"Jonathan D. Proulx" <[EMAIL PROTECTED]> wrote:
>On Thu, Jan 25, 2001 at 07:11:26PM +, Colin Watson wrote:
>:It could be someone trying an NFS exploit against your system, though
>:potato systems shouldn't be vulnerable to it.
>
>I'd s/could\ be/IS/;
Fair point - I wrote that, then saw the /bi
On Thu, Jan 25, 2001 at 07:11:26PM +, Colin Watson wrote:
:It could be someone trying an NFS exploit against your system, though
:potato systems shouldn't be vulnerable to it.
I'd s/could\ be/IS/;
:>f
:>Jan 18 19:16:45 brockwell
:>^F/binF^D/shA0<88>F^G<89>v^L<8D>V^P<8D>N^L<89>^K<80>^A<80>^?
Brock Murch wrote:
> I have been getting this error every so often in the syslog:
>
> Is this a nfs-common bug? or a syslogd bug?
>
> running:
>
> Linux brockwell 2.2.17 #2 Thu Sep 14 06:08:37 EDT 2000 i486 unknown
>
> all packages from the stable upgrade of that
Brock Murch <[EMAIL PROTECTED]> wrote:
>I have been getting this error every so often in the syslog:
>
>Is this a nfs-common bug? or a syslogd bug?
>
>running:
>
>Linux brockwell 2.2.17 #2 Thu Sep 14 06:08:37 EDT 2000 i486 unknown
>
>all packages from the stable
Le jeu, 25 jan 2001 19:19:11, Brock Murch a écrit :
> I have been getting this error every so often in the syslog:
>
> Is this a nfs-common bug? or a syslogd bug?
It is an attack attempt.
Look in the archives of debian-security there was some discussions on
this on January, 9th
I have been getting this error every so often in the syslog:
Is this a nfs-common bug? or a syslogd bug?
running:
Linux brockwell 2.2.17 #2 Thu Sep 14 06:08:37 EDT 2000 i486 unknown
all packages from the stable upgrade of that time.
Jan 18 19:16:45 brockwell
Jan 18 19:16:45 brockwell
32 matches
Mail list logo
