Re: auto-mount NFS shares on boot
>>> - On some systems with static IP addresses (and >>> /etc/network/interfaces), I had the problem that even though the >>> interface was conisdered up and ready by the kernel, the switch it >>> was connected to needed 30s or so to realize that fully (and >>> packets were simply dropped beforehand). Since those systems also >>> needed to mount NFS... > >Then you need to talk to your networking guy and tell him to switch STP >off on that port (or switch to RSTP). > >Grüße, >Sven. Hi Sven, thank you for your promt answer. But what you are suggesting is, that I should get rid of the 30s delay, I guess. But my question is, what to do If I have (for whatever reason) such a delay. Even more precise what is going wrong (or is it realy wrong?) if I handle the delay in the way I mentioned. All the best, Hank -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/blu170-w138bd79d23318cf9ac8f554cd...@phx.gbl
Re: Re: auto-mount NFS shares on boot
Hi there, trying to mount nfs-shares at boot I have exactly the problem mentioned by Christian: (in Message-id: <558e8105.5030...@iwakd.de>) > - On some systems with static IP addresses (and > /etc/network/interfaces), I had the problem that even though the > interface was conisdered up and ready by the kernel, the switch it > was connected to needed 30s or so to realize that fully (and > packets were simply dropped beforehand). Since those systems also > needed to mount NFS... Christian then recommends applying a unit he calls wait-for-nfs-server. My problem now is that if I apply that unit (or do other tricks like a sleep in /etc/network/interfaces the mounts are there after booting, but I have errors like that in journalctl: Jul 14 16:07:02 hhh rpcbind[657]: Starting rpcbind daemon Jul 14 16:07:02 hhh rpc.statd[681]: Version 1.2.8 starting Jul 14 16:07:02 hhh rpc.statd[681]: Flags: TI-RPC Jul 14 16:07:02 hhh rpc.statd[682]: Version 1.2.8 starting Jul 14 16:07:02 hhh rpc.statd[682]: Flags: TI-RPC Jul 14 16:07:02 hhh rpc.statd[683]: Version 1.2.8 starting Jul 14 16:07:02 hhh sm-notify[684]: Version 1.2.8 starting Jul 14 16:07:02 hhh rpc.statd[683]: failed to create RPC listeners, exiting Jul 14 16:07:02 hhh rpc.statd[682]: failed to create RPC listeners, exiting Jul 14 16:07:02 hhh nfs-common[673]: Starting NFS common utilities: statd failed! Jul 14 16:07:02 hhh systemd[1]: nfs-common.service: control process exited, code=exited status=1 Jul 14 16:07:02 hhh systemd[1]: Failed to start LSB: NFS support files common to client and server. Jul 14 16:07:02 hhh systemd[1]: Unit nfs-common.service entered failed state. Jul 14 16:07:02 hhh kernel: FS-Cache: Loaded Jul 14 16:07:03 hhh kernel: RPC: Registered named UNIX socket transport module. Jul 14 16:07:03 hhh kernel: RPC: Registered udp transport module. Jul 14 16:07:03 hhh kernel: RPC: Registered tcp transport module. Jul 14 16:07:03 hhh kernel: RPC: Registered tcp NFSv4.1 backchannel transport module. Jul 14 16:07:03 hhh kernel: FS-Cache: Netfs 'nfs' registered for caching Why the flag and what does it mean? rpc.statd[681]: Flags: TI-RPC And the other errors: rpc.statd[683]: failed to create RPC listeners, exiting nfs-common[673]: Starting NFS common utilities: statd failed! systemd[1]: nfs-common.service: control process exited, code=exited status=1 systemd[1]: Failed to start LSB: NFS support files common to client and server. systemd[1]: Unit nfs-common.service entered failed state. and if I do a root@hhh:~# ps aux | grep rpc root 669 0.1 0.0 37168 2904 ?Ss Jul14 1:42 /sbin/rpcbind -w statd 681 0.0 0.0 37268 2876 ?Ss Jul14 0:00 rpc.statd --no-notify root 692 0.0 0.0 0 0 ?S< Jul14 0:00 [rpciod] root 907 0.0 0.0 10712 1460 ?SJul14 0:00 /usr/sbin/rpc.yppasswdd -D /var/yp/ypfiles -e chsh root 910 0.0 0.0 8520 1612 ?SJul14 0:00 /usr/sbin/rpc.ypxfrd root 2758 0.0 0.0 14192 2284 pts/0S+ 15:42 0:00 grep rpc So, rpc.statd is there, but why with the --no-notify option? To me it looks like rpc.statd gets started multiple times (why?) and that confuses me and the whole nfs mount process. Now the question is: Is that normal or should I worry about it? Do you (Christian) also get such errors in journalctl? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/blu170-w2165db8abb61d8aacac025cd...@phx.gbl
In-Reply-To=<558e8105.5030...@iwakd.de>&Subject=Re:%20Re:%20auto-mount%20NFS%20shares%20on%20boot
Hi there, trying to mount nfs-shares at boot I have exactly the problem mentioned by Christian: > - On some systems with static IP addresses (and > /etc/network/interfaces), I had the problem that even though the > interface was conisdered up and ready by the kernel, the switch it > was connected to needed 30s or so to realize that fully (and > packets were simply dropped beforehand). Since those systems also > needed to mount NFS... Christian then recommends applying a unit he calls wait-for-nfs-server. My problem now is that if I apply that unit (or do other tricks like a sleep in /etc/network/interfaces the mounts are there after booting, but I have errors like that in journalctl: Jul 14 16:07:02 hhh rpcbind[657]: Starting rpcbind daemon Jul 14 16:07:02 hhh rpc.statd[681]: Version 1.2.8 starting Jul 14 16:07:02 hhh rpc.statd[681]: Flags: TI-RPC Jul 14 16:07:02 hhh rpc.statd[682]: Version 1.2.8 starting Jul 14 16:07:02 hhh rpc.statd[682]: Flags: TI-RPC Jul 14 16:07:02 hhh rpc.statd[683]: Version 1.2.8 starting Jul 14 16:07:02 hhh sm-notify[684]: Version 1.2.8 starting Jul 14 16:07:02 hhh rpc.statd[683]: failed to create RPC listeners, exiting Jul 14 16:07:02 hhh rpc.statd[682]: failed to create RPC listeners, exiting Jul 14 16:07:02 hhh nfs-common[673]: Starting NFS common utilities: statd failed! Jul 14 16:07:02 hhh systemd[1]: nfs-common.service: control process exited, code=exited status=1 Jul 14 16:07:02 hhh systemd[1]: Failed to start LSB: NFS support files common to client and server. Jul 14 16:07:02 hhh systemd[1]: Unit nfs-common.service entered failed state. Jul 14 16:07:02 hhh kernel: FS-Cache: Loaded Jul 14 16:07:03 hhh kernel: RPC: Registered named UNIX socket transport module. Jul 14 16:07:03 hhh kernel: RPC: Registered udp transport module. Jul 14 16:07:03 hhh kernel: RPC: Registered tcp transport module. Jul 14 16:07:03 hhh kernel: RPC: Registered tcp NFSv4.1 backchannel transport module. Jul 14 16:07:03 hhh kernel: FS-Cache: Netfs 'nfs' registered for caching Why the flag and what does it mean? rpc.statd[681]: Flags: TI-RPC And the other errors: rpc.statd[683]: failed to create RPC listeners, exiting nfs-common[673]: Starting NFS common utilities: statd failed! systemd[1]: nfs-common.service: control process exited, code=exited status=1 systemd[1]: Failed to start LSB: NFS support files common to client and server. systemd[1]: Unit nfs-common.service entered failed state. and if I do a root@hhh:~# ps aux | grep rpc root 669 0.1 0.0 37168 2904 ?Ss Jul14 1:42 /sbin/rpcbind -w statd 681 0.0 0.0 37268 2876 ?Ss Jul14 0:00 rpc.statd --no-notify root 692 0.0 0.0 0 0 ?S< Jul14 0:00 [rpciod] root 907 0.0 0.0 10712 1460 ?SJul14 0:00 /usr/sbin/rpc.yppasswdd -D /var/yp/ypfiles -e chsh root 910 0.0 0.0 8520 1612 ?SJul14 0:00 /usr/sbin/rpc.ypxfrd root 2758 0.0 0.0 14192 2284 pts/0S+ 15:42 0:00 grep rpc So, rpc.statd is there, but why with the --no-notify option? To me it looks like rpc.statd gets started multiple times (why?) and that confuses me and the whole nfs mount process. Now the question is: Is that normal or should I worry about it? Do you (Christian) also get such errors in journalctl? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/blu170-w1250f1b909c4771d931d7fbcd...@phx.gbl
Re: AW: webmin-samba configuration problem
> Neither of you mentioned which version of webmin-samba and which> version of Debian this is. Sorry about that. We're running Woody, and the webmin-samba version is 0.94-7woody1. Also, the version of samba we are running is 2.2.3a-12.3 Thank you.Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam
webmin-samba configuration problem
We have created a user account remotely using Webmin, but it doesn't appear to be creating a Samba account automatically on the remote machine. The following error occurs: -- Error Failed to save user : samba::useradmin_create_ser failed : Undefined subroutine &samba::get_share called at /usr/share/webmin/samba/useradmin_update.pl line 8 -- We have selected in Samba Share 'configure Automatic Unix and Samba User Syncronisation,' as well as in User and Groups 'create user in other modules'. We are trying to establish whether this is an error on our part, or a possible bug with 'webmin-samba,' and if it is a misconfiguration at our end, any insight into solving the problem would be appreciated. Thank you. Do you Yahoo!? Yahoo! Search - Find what youre looking for faster.
