Am 14.05.2016 um 20:55 schrieb Benjamin Kaduk:
> This sort of permission error can also occur when the fileserver can't
> communicate to a ptserver, so it's also worth checking for error messages
> in the various log files.
The reason for the issue turned out to be a corrupted volume which I
fixed
On Fri, 13 May 2016, Karl-Philipp Richter wrote:
> Am 14.03.2016 um 14:24 schrieb Chas Williams:
> > Then you should have permission to read root.cell. Did you add admin
> > to the system:administrators group? Do the pts commands work?
> >
> > While poking around I found this gentoo document
Am 14.03.2016 um 14:24 schrieb Chas Williams:
> Then you should have permission to read root.cell. Did you add admin
> to the system:administrators group? Do the pts commands work?
>
> While poking around I found this gentoo document which seems to
> cover what you want:
>
>
On Sun, 2016-03-13 at 23:15 +0100, Karl-Philipp Richter wrote:
>
> Am 12.03.2016 um 17:03 schrieb Chas Williams:
> > You need to authenticate via aklog (or whatever you might using)
> > or restart the servers w/o authentication so that you can add
> > yourself to the necessary groups. Then you
Am 12.03.2016 um 17:03 schrieb Chas Williams:
> You need to authenticate via aklog (or whatever you might using)
> or restart the servers w/o authentication so that you can add
> yourself to the necessary groups. Then you can read the volumes.
I'm authenticating with `kinit admin@[host]` as
On Wed, 2016-03-09 at 13:39 +0100, Karl-Philipp Richter wrote:
> Hi,
>
> Am 07.03.2016 um 21:19 schrieb Chas Williams:
> > Yes, that part of the manual is out of date when it comes to dynroot.
> > You don't need to setup replication for /afs (root.afs) since it doesn't
> > really exist. You
Hi,
Am 07.03.2016 um 21:19 schrieb Chas Williams:
> Yes, that part of the manual is out of date when it comes to dynroot.
> You don't need to setup replication for /afs (root.afs) since it doesn't
> really exist. You still access the R/W path to your local cell via
> /afs/.CELLNAME though.
On Mon, 2016-03-07 at 15:06 +0100, Karl-Philipp Richter wrote:
>
> Concretely, in section 2.24:
>
> - So 1. basically wants to say if `-dynroot` is enabled, then 1. isn't
> necessary and no alternative action needs to be performed? Anything else
> isn't possible, but the reader still wonders
Am 07.03.2016 um 06:18 schrieb Benjamin Kaduk:
> It is certainly possible to update the quickstart guide. Concrete
> references to a section number or HTML url wherein you want the change to
> be made would help.
>
> Looking at http://docs.openafs.org/QuickStartUnix/HDRWQ80.html, I see:
>
> %
On Sat, 5 Mar 2016, Karl-Philipp Richter wrote:
>
> Am 06.03.2016 um 00:46 schrieb Brandon Allbery:
> > That documentation sounds out of date, or possibly just incomplete.
> The sequence described in 2.24 doesn't correspond to what you mention...
> and to make sense.
>
> > When the client is
Am 06.03.2016 um 00:46 schrieb Brandon Allbery:
> That documentation sounds out of date, or possibly just incomplete.
The sequence described in 2.24 doesn't correspond to what you mention...
and to make sense.
> When the client is using an actual root.afs volume, the command you gave will
>
That documentation sounds out of date, or possibly just incomplete.
When dynroot is enabled, /afs is virtual and you cannot set the ACL. When the
client is using an actual root.afs volume, the command you gave will only work
before a read-only replica has been created and released (vos addsite
Hi,
I'm having trouble with `fs setacl /afs system:anyuser rl` with fails
with `fs:'/afs': Connection timed out` if `-dynroot` is enabled or `fs:
You don't have the required access rights on '/afs'` if `-dynroot` isn't
enabled. `tokens` contains `User's (AFS ID 1) tokens for
a...@richtercloud.de
13 matches
Mail list logo
