June 29, 201313 yr Having some problems with my tower lately. Currently running 5.0-rc15a, 12 before that, and 5 before that IIRC. Set everything up using AFP only, since I have an all Mac network. Everything ran fine for about 6 months, and now, over the last few months, things have slowly been going downhill. First, connecting to a share, getting a directory reading from a share became incredibly slow – about 1 minute to get a directory listing of any size folder. I chalked this up to having added lots of data to the server, lots of files in the share, etc. Then, my TimeMachine backups started getting corrupted on my MacBook Air, system asking me to start a new backup. It would do this every few months. I chalked this up to it being a portable, and often disconnecting from the network during a backup, etc. Then a week or so ago, shares started suddenly disconnecting. Finder gave a "The share does not exist on the server. Please check the share name, and then try again" message. Connected to the admin panel, and the list of shares was empty. Rebooted the server, shares where there as expected. It's been doing this for the last couple of days. Ran a parity check, everything was OK. I upgraded the system to rc15a, but that hasn't helped. so: - the AFP weirdness may or may not be related to the user share problems - but I'm concerned about the user share problems. Sorry for this long, rambling, imprecise question, just wondering if anyone might have an idea what's going on. I mention the AFP stuff only for completeness. I'm activating SMB for testing, will report back if that changes anything. thanks.
June 29, 201313 yr Author SMB isn't working well either. I turned it on for one of my user shares – it appeared, and I was able to connect to the share, but it conked out after a minute and now I can' even connect to it any more, Finder says it can't be found.
June 30, 201313 yr Author Attached is a .zip of a few of the most recent syslogs. thanks! syslog-20130627-to-30.zip
June 30, 201313 yr Author Attached is perhaps a better log file, which I just grabbed from the server as per the troubleshooting guide, and which covers a time in which the server dropped an AFP connection. there's a lot of "Transport endpoint is not connected" in there. syslog-2013-06-30.txt
July 1, 201313 yr Author I tried running reiserfsck, but the telnet session was cut off: ~# reiserfsck --check /dev/md1 ... reiserfsck --check started at Mon Jul 1 16:09:41 2013 ########### Replaying journal: Done. Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. \/ 5 (of 29// 57 (of 91|/ 19 Connection closed by foreign host. and the last few lines of my syslog read thus: Jul 1 16:08:39 zetta login[3510]: ROOT LOGIN on '/dev/pts/0' from '10.0.1.21' Jul 1 16:11:20 zetta unmenu[1296]: df: `/mnt/user': Transport endpoint is not connected Jul 1 16:11:21 zetta last message repeated 7 times Jul 1 16:20:53 zetta kernel: mdcmd (41): spindown 2 Jul 1 16:20:53 zetta kernel: mdcmd (42): spindown 3 Jul 1 16:20:54 zetta kernel: mdcmd (43): spindown 4 Jul 1 16:20:54 zetta kernel: mdcmd (44): spindown 23 Jul 1 16:24:45 zetta kernel: mdcmd (45): spindown 0 Jul 1 16:39:06 zetta kernel: mdcmd (46): spindown 1
July 9, 201312 yr Author I've now run reiserfsck directly on the machine. All of the disks seem to be fine. The summary screen at the end of the check is always more or less the same (transcribed by hand here) resierfsck --check No corruptions found. There are on filesystem: Leaves 72471 Internal nodes 4603 Directories 131146 Other files 1720429 Data block pointers 414009836 (2842 of the are zero) Safe links 0 anything else that I could look at which might explain strange behavior?
Archived
This topic is now archived and is closed to further replies.