Package Details: openafs 1.8.5-1

Git Clone URL: (read-only)
Package Base: openafs
Description: Open source implementation of the AFS distributed file system
Upstream URL:
Licenses: custom:"IBM Public License Version 1.0"
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.50
First Submitted: 2006-02-01 17:18
Last Updated: 2019-10-24 19:15

Latest Comments

1 2 3 4 5 6 ... Next › Last »

drslmr commented on 2017-11-24 14:02

Hi, I had some issue concerning ypbind together with logging into my afs account where I have my home directory under afs. See
In the above communication there was one workaround suggested to give the appropriate privileges to the login process, which works for me. But the better option would be to use nscd or sssd instead of yp.
Does anyone have any experience using nscd or sssd with logging into an afs account?

drslmr commented on 2017-11-06 13:06

Unfortunately I could not find out what exactly caused my recent issue. But from a former snapshot of my installation that did not have the issue it was possible to upgrade to today's state. And now the issue is gone.

drslmr commented on 2017-11-04 09:50

Bevan, thanks a lot for your effort. I'm sorry for taking your time.
On a different machine I did update openafs and linux to 4.13.11-1-ARCH and I can not reproduce the problem. Too, on my ill machine I can still use an older snapshot of an complete arch installation without the reported issue. So I guess something went wrong during upgrading. I remember that at some point during post installation hook my disk ran out of space. I think it was due to openafs-modules-dkms. I removed parts of /var/vache and tried to reinstall every package again. But still something is wrong. It's my problem.

Thanks again.

Bevan commented on 2017-11-03 14:05

drslmr: This sounds more like an issue with your AFS cell to me. If it's not, I guess it would be an upstream bug as I don't think we touch any code that's relevant for that.

Can you try to debug this with your cell provider? I did a small test in a local test cell and it worked as expected with kernel 4.13.10-1-ARCH and the current openafs packages:

1. Created a user for an IP range:
2. Created a group containing this user named localnet
3. Set ACLs for a folder to only allow access by group localnet
4. Within this directory I created another folder only accessible for my authenticated user

Without a token I could access the folder from step 3 from my local network and after obtaining a token I could also enter the folder from step 4.

One thing that does not work is giving the IP-based user (i.e. permissions via ACLs. This is on purpose and documented in

drslmr commented on 2017-11-03 09:59

Since last linux and openafs upgrade I can't access my directories anymore.
In the directory tree I can see directories only down to a certain level.
As soon as there is an additional IP based access right required I don't
see the directories anymore. This IP based access right seams to require that
the hosts IP address belongs to a certain set of IP sub-nets. I have no clue how that works. But it seams to not work anymore now.

kgizdov commented on 2017-10-24 21:00

latest version compiles for me fine.

totsilence commented on 2017-10-24 10:32

I prepared a patch and submitted it here as an OpenAFS bug:

I guess they will move the patch to gerrit if they agree with it. The patch solves the linking issue for me.

Bevan commented on 2017-10-23 17:23

Good catch! So it is caused by the latest ncurses update:

Searching the web for "ncurses with-termlib=tinfo" shows that this is/was an issue for other software packages as well. I guess the configure logic needs to be extended for again.

I won't have time to look into this today. If you come up with a patch we can directly send it upstream for review.

totsilence commented on 2017-10-23 17:13

I can reproduce the linking issue as well. It is related to missing "LINES" symbol which is part of in our ncurses package and -ltinfo is missing in some linker commands. When adding -ltinfo things build. Probably another patch to openafs autotools files is required.

Bevan commented on 2017-10-23 16:57

Mmh.. I think we are actually having two different issues here:

1) Infinite loop on configure: For some reason this seems to only occur on some systems. I cannot reproduce it. However, thanks to totsilence there is a patch which I now applied to all three openafs packages.

2) Linking error when trying to build openafs. This issue I can reproduce and it only occurs when building the openafs package. The module packages build fine. Unfortunately, the curses patch does not fix this issue although the error points into a similar direction (maybe the latest ncurses update?) So this is still unfixed...