Iuri Guilherme dos Santos Martins wrote: > It seems that now everytime I try to open the remote folders on > Nautilus I just recieve the "DBus error > org.freedesktop.DBus.Error.NoReply: Message did not receive a reply > (timeout by message bus)". I don't know about this message. > One thing that I am aware of and no it can't be solved is that the > clocks can't work correctly. The machines don't have good battery and > the clocks are not working well, resulting in machines with wrong time > settings and not all machines on the network having the same clock > settings. You have known clock problems? The time is not in sync across your collection of hosts? That is bad by itself. You should definitely take care that your clocks are updated. The dead battery should make no difference. All that means is that the system can't get the time at boot from the hardware clock. Instead the system will need to get the time from the network at boot time. That is okay. That is quite normal. > I have tried dpkg-reconfigure for nfs-kernel-server, nfs-common, > nautilus and tzdata in all machines with no luck. > > Could it be the clock settings the ONLY issue? Regardless of whether it is the only issue, it should be the first issue you fix. Then if the other problem you are having is still a problem then you can worry about it. First thing to do is fix the clocks. # apt-get install ntp The defaults are okay for single standalone machines. Doing the above on any random machine should be enough. If the time is really wrong then you should reboot so that all processes are restarted and the configuration can get the time from the network at boot time. Optimization Details: You said you have ten machines. Definitely for you I would configure the local systems to "peer" time with each other. If you only have ten and they are all the same, say all desktops, then I would have all of them peer with all of them. This is not elegant and uses more force than needed but works. File /etc/ntp.conf entries: server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst peer desktop1 iburst peer desktop2 iburst peer desktop3 iburst peer ... peer desktop10 iburst The above would be okay if you have a small network of ten machines. The "peer"ing allows them to share time with each other. That is a good thing to do. The result will be much better than if they can only get the time from the WAN due to WAN glitches. The LAN is more reliable and allows the sum to be much better than the parts. More optimization is possible. If two or three of those machines are "top level" machines on your network and there is some hierarchy then I would embrace that hierarchy. It is a burden on the networked time servers to be serving so many machines from a single local site. I would set up the top level machines to get time from the network. The upstream ntp docs recommend four local timeservers. I have found three to be quite good. That way the network time servers only see two, three, or four at max sytems "loading" them from your site. Then have all of the rest of the machines get time from your site timeservers. Your two or three top level machines: server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst peer topserver1 iburst peer topserver2 iburst peer topserver3 iburst The rest of your systems: server topserver1 iburst server topserver2 iburst server topserver3 iburst The ntpd knows its own name. It is okay to have its own hostname in the file on that host. That makes it easy to have the same file on multiple machines including machines where it is serving or peering time itself. With any of the three config cases above your machines should all now be very closely in time sync with each other. Hopefully any time problems you have having should go away. Hint: Check the ntpd status using 'ntpq -p'. I can say more about debugging those later if you need. > On dmesg I keep receiving this kind of thing: > > [ 135.896580] gvfsd-dav[3597]: segfault at 0 ip b717fbeb sp bfca73dc > error 4 in libc-2.13.so[b705f000+15c000] "segfault" is completely different from time problems and from NFS and SAMBA problems. "segfault" means that a process had a segmentation fault. That is most often due to program bugs. (If you access an array so far out of bounds that it is outside your program memory space for example.) Often due to shared library version mismatches. Double check that your system is up to date. Sometimes this will be due to faulty ram causing memory errors. If this is on one machine only then I would suspect ram. If this is across several machines then I would suspect a software shared library problem. If this is one program then I suspect a program bug. Since this seemed to have been gvfsd-dav only then I suspect either a bug in it or a mismatch against shared libraries that it is loading. Good luck! Bob
Attachment:
signature.asc
Description: Digital signature