Package Details: openafs 1.8.8-2

Git Clone URL: (read-only, click to copy)
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.000013
First Submitted: 2006-02-01 17:18
Last Updated: 2021-12-01 16:36

Latest Comments

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

bidulock commented on 2021-11-30 21:29

Need to add libxcrypt to depends.

kaspi commented on 2021-10-25 12:31

Hi Bevan, indeed, it is most likely this (unfortunate) outage. Thanks for pointing it out!

Bevan commented on 2021-10-25 11:26

Hi Jan. Could that be caused by this outage?

kaspi commented on 2021-10-25 11:10

Hi all,

after updating the system, I have troubles using AFS (details follow) and I wonder if anyone experiences the same or potentially would know how to fix it.

The SW versions which I use: kernel 5.14.14-arch1-1, openafs 1.8.8-1 and openafs-modules 1.8.8-2. The first problem occurs when running aklog:

Authenticating to cell (server
Trying to authenticate to user's realm CERN.CH.
Getting tickets: afs/
Using Kerberos V5 ticket natively
About to resolve name jkaspar to id in cell
# here it hangs for a minute
Error -1
Setting tokens. jkaspar @

Then, trying to ls a directory on AFS, I get a time out:

> ll /afs/
ls: cannot open directory '/afs/': Connection timed out

Thanks in advance,


drslmr commented on 2021-10-08 06:38

Yes, it works for me now with: linux 5.14.8.arch1-1 openafs-modules-dkms 1.8.8-2

Thank you very much.

Bevan commented on 2021-10-07 19:41

The potential RIP with kernel 5.14 should be fixed by openafs-modules-1.8.8-2 and openafs-modules-dkms-1.8.8-2. See for the ongoing review of the fix.

Bevan commented on 2021-10-06 07:29

drslmr: Thanks for noticing us here. The same error has been reported on the openafs mailing list:

So far, it could not be reproduced but with your report it becomes pretty clear that it is an issue with 5.14.8 / 5.14.9 specifically. I will forward your report to the mailing list as well so this issue can be sorted out quickly.

drslmr commented on 2021-10-06 05:58

I reported a kernel bug, that may have to do with afs:

Bevan commented on 2021-03-25 09:44


For AFS blocking reboot/shutdown having some effective KillMode could indeed help. When restarting the service we need to be careful: As far as I know, the openafs module needs to be reloaded before afsd is started again. I guess if systemd kills afsd, ExecStop=/usr/bin/rmmod openafs won't be executed afterwards. Also I'm not entirely sure if one even can unload the module if afsd crashed / was killed. Or if afsd is even killable. So I think we need to test this.

I myself only have a little test cell available where it's hard to reproduce these hang-ups. Could you test a modified service file in your environment for a while and report back? It uses KillMode=mixed and adds a few checks on startup to make sure that we do not run into some undefined behavior on restarts.

You can just save the following file as /etc/systemd/system/openafs-client.service:

Description=OpenAFS Client Service dkms.service

ExecStartPre=/bin/bash -c "findmnt /afs >/dev/null; test $? -ne 0 || (echo /afs is still mounted -- not starting && exit 1)"
ExecStartPre=/bin/bash -c "pidof afsd >/dev/null; test $? -ne 0 || (echo AFS client appears to be still running -- not starting && exit 1)"
ExecStartPre=/bin/bash -c "/usr/bin/lsmod|grep openafs >/dev/null; test $? -ne 0 || (echo openafs module still loaded -- not starting && exit 1)"
ExecStartPre=/usr/bin/modprobe openafs
ExecStart=/usr/bin/afsd $AFSD_ARGS
ExecStartPost=/usr/bin/fs setcrypt on
ExecStop=/usr/bin/umount /afs
ExecStop=/usr/bin/afsd -shutdown
ExecStop=/usr/bin/rmmod openafs


kgizdov commented on 2021-03-23 09:42

is it possible to adjust the KillMode=none in the service file to KillMode=control-group or KillMode=mixed at least? I've had the issue of AFS blocking reboot/shutdown or not being able to restart the service, because systemd can't manage it properly.