Hello Andy and Wilko, Yes I realise it is due to the software version I am running on this dataserver. The september one did not support writting. I cannot use the latest online versions due to the DNS problem crashing xrootd. What I could do would be to use a version from January but these are not downloadable anymore! Why do you hide older versions? Do I have to do a website 'mirroring' so that I can use, in the future, the software version I need? Cheers, Gregory On Wed, 30 Mar 2005, abh wrote: > Hi Gregory & Wilko, > > Yes, now I recall. Sorry, I though you were running the latest version. The > version you are running was not able to export more than one directory. > Thanks Wilko for reminding me of that! > > Andy > > ----- Original Message ----- From: "Wilko Kroeger" <[log in to unmask]> > To: "Gregory Schott" <[log in to unmask]> > Cc: "abh" <[log in to unmask]>; "Peter Elmer" <[log in to unmask]>; > <[log in to unmask]> > Sent: Wednesday, March 30, 2005 5:50 PM > Subject: Re: xrootd meeting - Tuesday 29 March, 2005 > > >> >> Hello Gregory >> >> Does it work to write to root://f01-001-124:1094////tmp/dummy.root ? >> I just installed your version and I also see that I can't write to xrootd >> except /tmp. Even in this case the message, >> Error accessing path/file for root://datadevsol01:2094////tmp/trds.test >> is printed but the file is actually transfered. >> >> Could you install a newer version of xrootd? I see that you are using the >> version 20040907-0403 which is quite old. The best would be to use the >> version 20050328-0656. >> >> Cheers, >> Wilko >> >> >> >> >> >> On Thu, 31 Mar 2005, Gregory Schott wrote: >> >>> Hello Andy, >>> >>> About my writing problem... >>> >>> I got confused and probably got you confused too but I don't want (and >>> need) this machine to be managed by the redirector. I had however >>> forgotten to comment the odc.manager option. >>> >>> == >>> >>> My config file is then the following (I believe it is a config file >>> problem): >>> >>> # dataserver.cf >>> # >>> oss.alloc * * 80 >>> oss.fdlimit * max >>> oss.localroot /home/xrootd/disk/kanga/EventStore/ >>> #oss.path /home/xrootd/disk/kanga/EventStore/ writable >>> >>> xrd.protocol xrootd * >>> >>> xrootd.export /prod >>> xrootd.export /store >>> xrootd.fslib /home/xrootd/software/current/lib/libXrdOfs.so >>> >>> odc.trace redirect >>> olb.trace all >>> oss.trace all >>> xrd.trace all >>> xrootd.trace all >>> >>> == >>> >>> The error message I get with xrdcp is: >>> >>> Error accessing path/file for root://f01-001-124:1094//prod/dummy.root >>> >>> PS: I can actually read the file if I xrdcp the other way around so the >>> path is accessible for read. According to the documentation the default is >>> write allowed (except if I use oss.readonly). The unix directory rights >>> also allow xrootd to write there. >>> >>> == >>> >>> And in the (verbose) log file is: >>> >>> 050331 01:51:45 15028 Exporting /store >>> 050331 01:51:45 15028 Exporting /prod >>> 050331 01:51:45 15028 XRootd protocol version 2.2.0 build 20040907-0403 >>> successfully loaded. >>> 050331 01:51:45 15028 xrd@f01-001-124:1094 initialization completed. >>> 050331 01:51:45 15028 XrdMain: thread 10251 assigned to user handler >>> 050331 01:52:14 15042 XrdNet: Accepted tcp connection from >>> l01-001-122.gridka.de >>> 050331 01:52:14 15042 ?:[log in to unmask] XrdUser: connection >>> accepted >>> 050331 01:52:14 15035 XrdSched: new worker; tid=11276; num=2 >>> 050331 01:52:14 15035 XrdSched: running [log in to unmask] inq=0 >>> 050331 01:52:14 15035 XrdProtocol: matched protocol xrootd >>> 050331 01:52:14 15035 ?:[log in to unmask] XrdPoll: FD 13 attached >>> to poller 0; num=1 >>> 050331 01:52:14 15035 ?:[log in to unmask] XrootdProtocol: 0000 >>> req=3007 dlen=0 >>> 050331 01:52:14 15035 xrootd.12395:[log in to unmask] >>> XrootdResponse: 0000 sending OK >>> 050331 01:52:14 15035 XrootdXeq: User logged in as >>> xrootd.12395:[log in to unmask] >>> 050331 01:52:14 15035 xrootd.12395:[log in to unmask] >>> XrootdProtocol: 0000 req=3010 dlen=16 >>> 050331 01:52:14 15035 ofs_open: xrootd.12395:[log in to unmask] >>> Unable to create /prod/dummy.root; No such file or directory >>> 050331 01:52:14 15035 xrootd.12395:[log in to unmask] >>> XrootdResponse: 0000 sending err 3011: Unable to create /prod/dummy.root; >>> No such file or directory >>> 050331 01:52:14 15035 xrootd.12395:[log in to unmask] XrdPoll: >>> sending poller 0 detach for link 13 >>> 050331 01:52:14 15036 XrdPoll: Poller 0 detached fd 13 entry 1 now at 1 >>> 050331 01:52:14 15035 xrootd.12395:[log in to unmask] XrdPoll: FD 13 >>> detached from poller 0; num=0 >>> 050331 01:52:14 15035 XrdLink: xrootd.12395:[log in to unmask] >>> disconnected after 0:00:00 >>> >>> >>> -- Gregory >>> >>> >>> >>> On Tue, 29 Mar 2005, abh wrote: >>> >>> >> 050329 19:08:51 6914 odc_Open: Unable to connect socket >>> >> /tmp/.olb/olbd.admin; connection refused >>> > Is teh log truncated or did this connection succeed? >>> > >>> > >>> >> bash-2.05a$ cat config/dataserver.cf >>> >> odc.manager babar2 3121 >>> > Probably doesn't make a difference but one should expand this out > >>> completely >>> > with the domain name. >>> > >>> >> #olb.subscribe babar2 3121 >>> > Same thing about expansion. However, why is this commented out? With a >>> > sunscribe entry, no data server will particpate in the setup. So, this > >>> system >>> > should not work (in fact it should complain and the olbd should exit on >>> > the >>> > adat servers). >>> >> >