OpenBSD Journal

OpenAFS on OpenBSD needs help

Contributed by jose on from the kick-ass-distributed-filesystems dept.

Gabriel Kihlman writes:
"Jim Rees has put up an effort to get OpenAFS running on OpenBSD. So far lots of people have asked for it but he has had little feedback on the work he has done.

"I am eagerly awaiting bug reports on any part of the OpenBSD port.Considering how much interest people have expressed, I would have expected at least one report by now. So if you have OpenBSD, please test and report back to me."

This was back in november 2002 and there has been almost no response on the mailinglist so I guess a wider audience would be good. Lets just not swamp him with beginner questions about AFS eh?

There are excellent docs on setting up AFS on "

If you haven't looked at what AFS is you're missing out. Jim's work is awesome given that the Arla AFS implementation which ships in OpenBSD is only semi-functional. And now you don't have to change the OS on that machine to have a working AFS server. Try it out and help Jim and the OpenAFS people get this working cleanly on OpenBSD.

(Comments are closed)

    1. By anders () on

      For example, a Contributor might include the Program in a commercial product offering, Product X. That Contributor is then a Commercial Contributor. If that Commercial Contributor then makes performance claims, or offers warranties related to Product X, those performance claims and warranties are such Commercial Contributor's responsibility alone. Under this section, the Commercial Contributor would have to defend claims against the other Contributors related to those performance claims and warranties, and if a court requires any other Contributor to pay any damages as a result, the Commercial Contributor must pay those damages.
      [end quote]

      What is this supposed to solve? Is it just IBM defending itself?

      1. By Anonymous Coward () on


        You sell it, you support it.

        For people potentially selling OpenAFS:(Commercial Contributer)

        If _your_ customer that _payed_you_ for the stuff tries to sue everyone(or anyone) that contributed code or docs. _You_ will handle it, and _you_ will not (cannot) hold anyone else responsible (Indemnified Contributers).

        If _your_ customer sues an indemnified contributer successfully _you_ pay the fine.

  2. By Rick Wash () on

    Disclaimer: I work at CITI with Jim Rees.

    Jim's AFS work is working on my desktop at CITI. I regularly use my -current OpenBSD machine w/ AFS to access the university's AFS servers. IIRC, it was pretty easy to set up, but I also had Jim looking over my shoulder at the time.

    1. By couderc () on

      I'll be really curious about which version you use.
      I've started a port of the 1.2.8 version and have seen so much bad things.
      First openafs does just support i386 arch of openbsd.
      The main problem is the fact that openafs use a des header different than the one we get in the base system which results in type conflicts.
      I've also found some flaws with pointers.

      I am also suprised that you had no difficulties to install openafs as there is no rx support for openbsd (i've used freebsd code to make it "working").

  3. By mirabile () on

    You know we have Arla AFS in the base install?

    OTOH I don't know about stability, usability or
    even if a server is included.
    I never really found the time to learn AFS, so
    I use scp and smb here...

    1. By Anonymous Coward () on

      > You know we have Arla AFS in the base install?

      Are you too lazy to read the freaking article above or just stupid???

      From the article:
      > Arla AFS implementation which ships in OpenBSD is only semi-functional.

    2. By couderc () on

      Well, if you look solutions for network filesystem you'll find that :
      - nfs : no comment ;)
      - smb : no more ...
      - coda : no reply => almost dead
      - intermezzo : too much linux
      - sprite,dfs, etc ... => dead
      - afs : 2 solutions : arla => no working server, openafs => not useable actually.

      An afs server is really lacking for people who don't want to use nfs or smb.

      1. By RC () on

        Well, you do have a semi-point there, but you missed one:

        NFS over SSH.

        NFS may have it's problems, but it's quite stable at this point. Encrypted FSes like TCFS use loopback NFS, so even there, NFS is doing much of the back-end work.

        In addition, I would strongly like to see a MOUNT_SCP option for OpenBSD (as well as all the other systems), as I believe SCP makes a better remote FS than just about anything else out there.

        The last time I brought this up, I had some opposition from fans of AFS, but I believe that the enterprise features of other remote filesystems (such as multiple servers acting as one large remote filesystem) could be made to work with scp without too much difficulty.

        1. By tedu () on

          we don't need MOUNT_SCP. we need an easy to use, flexible framework for userland file systems. it's already there, xfs. (which is used to support AFS). but nobody has ever tried to use it to make another userland file system deamon.

        2. By click46 () on

          I'm sorry, but I was under the impression that SCP was just a file-level transfer method, not a block level filesystem. how in the world would you "mount" an "SCP"....file?

          I may have used the wrong terminology but I think you know what I'm getting at. How the hell would mounting an scp whatever even work?

          1. By Niall O'Higgins () on

            While I am in no way recommending SCP for the basis of a network filesystem, Linux already has this capability:


            It even has GNUtella FS support, the madness!

    3. By Jan J () on

      The arla version that ships with OpenBSD (0.35.7) is not very good (to put it nicely). You want 0.36pre??, it works with GENERIC kernel and is quite stable. However there is a lack in the administration commands such as 'vos release' that has not been implemented yet.

      0.36 won't build on sparc64 because the Kerberos libs are messed up. This should be fixed at the next hackaton where a new Heimdal should be imported (and maybe a new arla).

      The last status i can remeber on milko (the arla AFS server) is "It is great to put CDs in AFS because the won't get corrupt".

  4. By dawg () on

    I have been testing obsd and samba out in many different conditions and wonder if someone could address the following for me as they have been sticking points for me integrating smb with obsd.

    1. It looks like afs is primarily set up for kerberos interoperability. Are there any issues/limitations with regard to the heimdal distro obsd uses?

    2. Using smb file shares with samba on obsd still requires requires local unix user accounts on the file server to satisfy underlying uxix file security. If using kerberos with afs, is that requirement still applicable?

    3. Are there any acl issues as there are with obsd/samba?

    Thanks in advance.

    1. By Jan J () on

      1: There is a hole in kadmind (patch 001) fix that or you will loose. Otherwise I know of no problems. We run our Kerberos on OpenBSD/sparc64 3.2-current with some 2000 users and not a hickup.

      2: The AFS fileserver know nothing about the filestructure. I delivers volumes (or part of volumes) to the client. The client builds the filestructure following mount points for new volumes to fetch from the server. As such the fileserver needs no users. The users are instead put in the pts (protection database). Users have three entries. Kerberos: username + password. pts: username (and groups for AFS). /etc/passwd: The normal line which gives them access to workstations.

      3: Not sure what you mean by this but I try anyway.

      Exporting AFS with samba is a pain in the but. You need to send your password in cleartext to the samba server so that it can by an AFS token for you. Compiling Samba with AFS support i a pain in the but.

      Many programs do not understand AFS they will do stat() on a file and say "You don't have access" even if AFS says "You have full access". This is solved by chmod 777 or something like that.

      1. By dawg () on

        So are you saying that all security is handled by the frontend server?

        If so,

        Is that because the front end server proxies the kerberos ticket for the user?

        Would you need an account on the backend servers for the front end server to gain access to the files?


        1. By Jan J () on

          For AFS access from Windows first try the AFS client for Windows. When we started out this was not available so the solution was to use Samba. You might call it a SMB to AFS translator. We are now doing everything we can to move away from this.

          This is how it works here.

          Student logs in to the local computer using a guest account.

          Student chooses "Map network drive" with SAMBAhome, and enters his Kerberos information.

          The samba server verifies with /etc/passwd that there is such a user and then with Kerberos that the password is correct. It also gets an AFS token (a type of Kerberos ticket) which give the user access i AFS.

          Now 'Student' opens the document 'mydoc.doc'.

          The windows client sends a SMB request to the Samba server which finds that this is in AFS and the AFS client (on the Samba server) the retrieves the file from the AFS fileserver checking with the AFS protection database that the user is allowed to access this file.

          When the file has been retreived to the AFS cache on the Samba server it is sent back with SMB to the Windows client.

          The cons are:

          - Redundancy is lost. Since all file access is going through the Samba server. If it goes down your windows clients can't access their files. With "normal" AFS files can be only many fileservers and home dir's will be spread out on multiple server so a sever crash a part of your users not all.

          - All the Windows clients share one AFS cache which makes the cache pretty pointless.

          - Password is sent in cleartext so that the Samba server can get Kerberos tickets with it.

          - The files will go through serveroom switches atleast three times which is a waste of bandwidth. (Client samba AFS)

          - When browsing AFS through Samba. Samba or Windows stats() which makes it very slow accessing directories where you don't have full access and /afs (where you have all foreing cells) take forever as it tries to figure out "How big is this folder" and what icon should it have. The AFS client fakes the info.

          The pros are:

          (There are no pros)

          Hope this answer your question.

          1. By Jan J () on

            The thing ate my signs.. <br> <br> The student maps SAMBAhome (backslahs, backslash, SAMBA, backslash, home) <br> <br> Files passthrough the serverroom switch as Client Samba AFS.

          2. By Anonymous Coward () on

            I went googling for a "free" AFS-client for windows and found this in the google cache.


            Seems like there is a windowsclient and an install instruction with it, hope that it can help you.

            1. By Jan J () on

              Yes. I know but thanks anyway.

              1.2.1 was the first version we tried. It didn't throw away the tickets when a user logged out so the next user that logged in could do bad stuff.

              1.2.2 fix this and has undergone extensive testing at our place. It is not quite "student" material in out opinion.

              Then there was a huge gap.

              1.2.8 is the first release in a long time. It seems to have fixed a few things. Still there is the problem with Swedish characters in filenames. I know it is bad but my users don't. :-)

              However it is good enough to replace the Samba and it will when we roll out our new Windows enviroment with Active Directory, Kerberos login, real AFS and so on.


    2. By Anonymous Coward () on

      AFS locks whole files, so you cannot have co-edited files on it

  5. By Anonymous Coward () on

    Help a software which license is not compatible
    with OpenBSD policy ? You must be kidding.

    ( is is an OpenBSD related site, right ?)

    1. By tedu () on

      you mean i shouldn't be allowed to use opera? there's a ton of software which isn't license compatible and probably never will be. but if that is the software which works, it makes sense to use it.

      you can help the arla project out too, if you're interested in AFS. But OpenAFS is looking a lot better for people who want AFS now.

      1. By Anonymous Coward () on

        Sure, but it will never make Base if that was
        Efforts, for openbsd developers (like you)
        should be directed to something that is "Base'able".
        The license should be changed no ? Or you agree with it ? Please view djm post, he's indeed right.

        1. By Anonymous Coward () on

          The efforts of openbsd developers are whatever they want them to be. Thier is a need and he is helping to deal with it.

          1. By Anonymous Coward () on

            Really ? Cool! Let's see the new license.
            Oh wait, he changed it recently, to something unacceptable. Damn it..
            I'm eager to see the 'efforts'.

    2. By Lars Hansson () on

      Meanwhile, in the real world, people are actually more concerned with a working environment than with license (flame)wars.

      1. By couderc () on

        In the real world you pay if you play games with license.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]