File Server access nightmare
in [UK Linux]
|
Prev: biew-6.1.0 has been released
Next: Installation Proglem
From: unruh on 16 Dec 2009 10:59 On 2009-12-16, Alan Secker <alan(a)asandco.co.uk> wrote: > Geoffrey Clements wrote: > >> "Alan Secker" <alan(a)asandco.co.uk> wrote in message >> news:ZdudnX4NO-CgLbrWnZ2dnUVZ8kadnZ2d(a)pipex.net... >>> Well, the log files didn't reveal anything suspect. >>> testparm was happy. >>> Restarting samba did not cause the same problems as rebooting. >>> File permissions were an unlikely suspect as everyone but me had complete >>> access. I checked my $HOME anyway.It was OK. >>> Neither SELiniux or appArmor had been deployed >>> smb.conf is at /etc/samba >>> >>> BUT, the server's clock was an hour out! >> >> One hour - that seems suspicious. Some questions come to mind: Is the >> server's clock on UTC or localtime? What time zone is the server set to? >> >> It's worth checking this or you might have the same problem again (in >> March maybe). >> > Good point but both are identical. Regards, Alan You need to answer the first part of his question as well. How is the time set on the server? Are you using ntp/chrony? Exactly what distributions are running on the various machines? Your server is apparently either starting up with the wrong time or is delivering the wrong time. It is about a month since daylight savings time started. Did your problems begin with that? If so I suspect your server is on localtime, not UTC. That is a very bad idea. Exactly what operating system is the server running. And your client. > > This afternoon (I was out this morning), my system came up and I went > straight to VirtualBox and Windows XP. The server files were inaccessible. > Clicked back to Linux. Ran through smb4k. No problem. Back to XP, now OK. > Head scratching stuff. > "ran through smb4k" means what?
From: Alan Secker on 18 Dec 2009 11:34 unruh wrote: > On 2009-12-16, Alan Secker <alan(a)asandco.co.uk> wrote: >> Geoffrey Clements wrote: >> >>> "Alan Secker" <alan(a)asandco.co.uk> wrote in message >>> news:ZdudnX4NO-CgLbrWnZ2dnUVZ8kadnZ2d(a)pipex.net... >>>> Well, the log files didn't reveal anything suspect. >>>> testparm was happy. >>>> Restarting samba did not cause the same problems as rebooting. >>>> File permissions were an unlikely suspect as everyone but me had >>>> complete access. I checked my $HOME anyway.It was OK. >>>> Neither SELiniux or appArmor had been deployed >>>> smb.conf is at /etc/samba >>>> >>>> BUT, the server's clock was an hour out! >>> >>> One hour - that seems suspicious. Some questions come to mind: Is the >>> server's clock on UTC or localtime? What time zone is the server set to? >>> >>> It's worth checking this or you might have the same problem again (in >>> March maybe). >>> >> Good point but both are identical. Regards, Alan > > You need to answer the first part of his question as well. How is the > time set on the server? Are you using ntp/chrony? Exactly what > distributions are running on the various machines? > > Your server is apparently either starting up with the wrong time or is > delivering the wrong time. It is about a month since daylight savings > time started. Did your problems begin with that? If so I suspect your > server is on localtime, not UTC. That is a very bad idea. > > Exactly what operating system is the server running. And your client. > > >> >> This afternoon (I was out this morning), my system came up and I went >> straight to VirtualBox and Windows XP. The server files were >> inaccessible. Clicked back to Linux. Ran through smb4k. No problem. Back >> to XP, now OK. Head scratching stuff. >> > "ran through smb4k" means what? The time between server and work-stations is not synchronised. I have never used UTC before. The server is running Mandriva Linux 2005 LE Work-stations run a variety of Mandriva from 2008.1 to 2010.0 The intention was to update all to 2010 but that is being thwarted by a separate problem. smb4k enables the Linux user to inspect the server's files. I only use it to test that I actually have access. Here, unless I ran through the process of executing it, scanning the network and providing authentication along the way, then my XP client cannot access the network files. This has only happened since I moved from vmware to VirtualBox. The latter is the cause of my latest headache!!!!
From: Nix on 21 Dec 2009 17:53 On 18 Dec 2009, Alan Secker verbalised: > The time between server and work-stations is not synchronised. Well there's your problem then. It is very unwise to share filesystems between machines with unsynchronized clocks; some protocols are confused by time skew as low as a millisecond, and apps are frequently confused if they write a file then find that it was allegedly written some time ago, or in the future. Caring about millisecond-scale skew is still relatively unusual, but differences as large an an hour are likely to throw off all sorts of things: the first that springs to mind is the election protocol used to pick a machine to populate e.g. the network neighborhood view. Run NTP on the clients and servers and your problems will be over. > I have never used UTC before. If you live in Britain you surely have, for half of each year.
From: Moe Trin on 22 Dec 2009 20:25 On Mon, 21 Dec 2009, in the Usenet newsgroup uk.comp.os.linux, in article <87ocls6ish.fsf(a)spindle.srvr.nix>, Nix wrote: >Alan Secker verbalised: >> I have never used UTC before. >If you live in Britain you surely have, for half of each year. [compton ~]$ /usr/sbin/zdump -v GMT | grep 2009 [compton ~]$ /usr/sbin/zdump -v UTC | grep 2009 [compton ~]$ /usr/sbin/zdump -v Europe/London | grep 2009 Europe/London Sun Mar 29 00:59:59 2009 UTC = Sun Mar 29 00:59:59 2009 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 29 01:00:00 2009 UTC = Sun Mar 29 02:00:00 2009 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 25 00:59:59 2009 UTC = Sun Oct 25 01:59:59 2009 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 25 01:00:00 2009 UTC = Sun Oct 25 01:00:00 2009 GMT isdst=0 gmtoff=0 [compton ~]$ GMT may be _equal_ to UTC, but quoting from tzdata2009s/europe source file lines 218 to 224: # From Joseph S. Myers (1998-01-06): # # The legal time in the UK outside of summer time is definitely GMT, not UTC; # see Lord Tanlaw's speech # <a href="http://www.parliament.the-stationery-office.co.uk/pa/ld199697 /ldhansrd/pdvn/lds97/text/70611-20.htm#70611-20_head0"> # (Lords Hansard 11 June 1997 columns 964 to 976) # </a>. (Watch the line-wrap on the URL). Same file, lines 424 to 429: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:01:15 - LMT 1847 Dec 1 0:00s 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u 0:00 GB-Eire %s 1996 0:00 EU GMT/BST so that's where your timezone file is picking up the GMT and BST names. The GMT and UTC (as well as UCT, Zulu and Greenwich) timezones are defined in the tzdata2009s/etcetera file which is for 'backwards compatibility'. Old guy
From: Russ Moore on 25 Dec 2009 21:51
On Wed, 16 Dec 2009 15:18:25 +0000, Alan Secker wrote: > herman.viaene(a)invalid.be wrote: > >> Alan Secker wrote: >> >>> For several days I have been experiencing difficulties in connecting >>> to my firm's file-server. This is a six work-station LAN using samba >>> to access common files. >>> >>> Shortly after replacing my work-station with a newer machine the >>> problems began. >>> >>> Today I decided to cold-boot the file server and log the results. This >>> is what happened: >>> >>> 1) Rebooted server. >>> 2) Powered up work-stations. None could 'see' the server. 3) Executed >>> samba restart on the server 4) All users could now ping the server 5) >>> Everyone except me could now 'see' and access common files on the >>> server >>> via smb4k. >>> 6) As I have had to do every morning for the last four working days, >>> on the >>> file server, I ran smbpasswd and re-entered my samba username >>> and password. >>> 7) Checked again via smb4k and could now access the server's files. >> >> A guess: your samba synchronizes with its host for the users, and your >> workstation user either does nor exist on the server, or it does exist >> with a different password? >> >> Herman Viaene >> > I don't think so.It has been on the file server for three years and I > have not changed passwords during that time. > > Regards, Alan This is abour 5-6 years ago so may be no longer relevant. Been ages since I played with Samba but I had a similar problem and it turned out to be the machine's password. To use a Domain you had to give not only each user but each machine an account/user on the server. User passwords where set to a default but machines were not. When a machine first connected it automagically added a password. I think a machine password was created from a hardware signature. So as you mentioned moving XP from one VM to another it is possible that this 'hardware' based signature also changed. Russ |