Cannot read files from OSX -permissions wonky

Help
2008-03-06
2013-05-08
  • The problem I am having is that I can mount the afp share, and I can traverse the afp tree after mounting, but I can not read any files unless they have the 'write' bit set on OS X.

    It's very odd.

    Can anybody else verify this, or provide an explanation/fix?

    (I tried running afpsd -d in another window, but it didn't seem to output anything that was useful.  I can run it again if you need, or anything else you may need...)

    R

     
    • Sorry...I should have stated that I am running the 0.8-1 .deb from here, on Ubuntu 7.10 (Gutsy) which uses libfuse2 2.7.0 

      R

       
    • Alex deVries
      Alex deVries
      2008-03-06

      Richard,

      That is indeed a strange error.

      There's two things that could help me with this:

      1. See if you can use the cmdline client to get access to this file, with something like:
      afpcmd afp://username:password@servername/volumename/dir/myworkingfile

      and then:
      afpcmd afp://username:password@servername/volumename/dir/mybrokenfile

      (you should put workingfile and brokenfile in a subdir on the volume)

      2. Grab a full tcpdump (with -s0) of the transaction; follow the instructions in REPORTING-BUGS.txt if you need more detail.  Get the dump using afpcmd if it fails, otherwise the FUSE client.  The afpcmd dump will be easier for me to follow.

      I encourage you to open a bug in the tracker.  If that's inconvenient, mail me directly.

      Thanks for reporting this!

      - Alex

       
    • M. P.
      M. P.
      2009-07-28

      Can verify the same problem here on Ubuntu 9.04 with the same deb-package. Files with writing-permissions can be access, others cannot be opened.

       
  • Bump. Same problem on Ubuntu 9.10:

    $ ls -latr
    total 0
    drwxr-xr-x 4 user1 group1  92 2010-02-26 15:51 .
    drwxr-xr-x 5 user1 group1 126 2010-02-26 15:50 ..
    -rw-r--r-- 1 user1 group1  21 2010-02-26 15:51 bar.txt
    -rw-r--r-- 1 user1 group1  21 2010-02-26 15:51 foo.txt
    $ cat *.txt
    This is a test file.
    This is a test file.
    $ chmod 444 bar.txt
    $ ls -la
    total 0
    drwxr-xr-x 4 user1 group1  92 2010-02-26 15:51 .
    drwxr-xr-x 5 user1 group1 126 2010-02-26 15:50 ..
    -r--r--r-- 1 user1 group1  21 2010-02-26 15:51 bar.txt
    -rw-r--r-- 1 user1 group1  21 2010-02-26 15:51 foo.txt
    $ cat *.txt
    cat: bar.txt: Permission denied
    This is a test file.
    

    Running on:
    Linux 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux

     
  • Alex deVries
    Alex deVries
    2010-02-28

    Is there any chance you could send me a tcpdump capture of when you do a:
    ls -l foo.txt
    and
    chmod 444 foo.txt

    ?

    - A

     
  • Sorry, can't post tcpdump. I'm connecting over secure VPN. Anything specific I should look for in the dump?

     
  • classicmac
    classicmac
    2010-05-31

    I'm seeing the same problem on Ubuntu 9.10.  If the file has rw permissions I can read it.  If it only has r I can't read it.  Here is output from tcpdump.  Thank you for developing this software.  I appreciate the effort you have put in to it.

    ****** Output from ls *****

    14:08:54.444404 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , seq 5248:5287, ack 12303, win 1002, options , length 39
    14:08:54.502575 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , ack 5287, win 32748, options , length 0
    14:08:54.502787 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , seq 12303:12399, ack 5287, win 32768, options , length 96
    14:08:54.502812 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , ack 12399, win 1001, options , length

    ****** Output from chmod 444 *****

    14:09:26.970613 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , seq 5287:5341, ack 12399, win 1002, options , length 54
    14:09:26.971828 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , ack 5341, win 32741, options , length 0
    14:09:26.971991 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , seq 12399:12425, ack 5341, win 32768, options , length 26
    14:09:26.972022 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , ack 12425, win 1002, options , length 0
    14:09:26.972233 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , seq 5341:5380, ack 12425, win 1002, options , length 39
    14:09:26.973359 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , ack 5380, win 32748, options , length 0
    14:09:26.976984 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , seq 12425:12521, ack 5380, win 32768, options , length 96
    14:09:26.977563 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , seq 5380:5419, ack 12521, win 1002, options , length 39
    14:09:26.978330 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , ack 5419, win 32748, options , length 0
    14:09:26.978706 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , seq 12521:12559, ack 5419, win 32768, options , length 38
    14:09:26.978852 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , seq 5419:5458, ack 12559, win 1002, options , length 39
    14:09:26.979955 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , ack 5458, win 32748, options , length 0
    14:09:26.980403 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , seq 12559:12655, ack 5458, win 32768, options , length 96
    14:09:27.024121 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , ack 12655, win 1002, options , length 0
    14:09:28.290807 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , seq 5458:5511, ack 12655, win 1002, options , length 53
    14:09:28.293847 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , ack 5511, win 32741, options , length 0
    14:09:28.294366 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , seq 12655:12713, ack 5511, win 32768, options , length 58
    14:09:28.294395 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , ack 12713, win 1002, options , length 0
    14:09:28.294734 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , seq 5511:5550, ack 12713, win 1002, options , length 39
    14:09:28.295508 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , ack 5550, win 32748, options , length 0
    14:09:28.295863 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , seq 12713:12809, ack 5550, win 32768, options , length 96
    14:09:28.296171 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , seq 5550:5589, ack 12809, win 1002, options , length 39
    14:09:28.296957 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , ack 5589, win 32748, options , length 0
    14:09:28.297886 IP hostname.afpovertcp > 10.0.0.2.58838: Flags , seq 12809:12829, ack 5589, win 32768, options , length 20
    14:09:28.336094 IP 10.0.0.2.58838 > hostname.afpovertcp: Flags , ack 12829, win 1002, options , length 0

     
  • lonb
    lonb
    2010-08-14

    Bump.  This happens for me as well. I've got Mac OS 10.6.4 and Ubuntu 10.04 (lucid lynx),  I'm able to mount the share (which is shared r/w from ye ole apple) and can browse the mount on mr. ubuntu.  However, if I try to copy or stream the files, I get permission probs.  I tried two files, one is set -rw-r-r- and the other -rwxr-xr-x.

    Ideas?

     
  • lonb
    lonb
    2010-08-14

    Actually, after reading this post on apple perms nightmare, I set all to 777 from the mac and it now works.  However, I'm not sure this is the right solution.

     
  • lonb
    lonb
    2010-08-15

    Sorry to keep replying, here's an update.  With the perms change I mentioned, I can begin to stream or copy files, however, they fail within second (~5-10 seconds) in.  Then the mount is unreadable at all. If I try to unmount it, I get "device is busy."  If I try to cd into the directory, the terminal hangs.

     
  • Danny
    Danny
    2012-09-13

    Was a solution ever discovered for this issue?  I'm seeing it too.

     
  • snaveekima
    snaveekima
    2012-12-29

    Hi - I think I have found the problem,  but I'm no coding genius so the following could be completely wrong: make your own mind up. Think this also relates to bugs 3314719 and 3165123.

    There seems to be a whole hierarchy of function calls in order to open a file:
    fuse_open (fuse_int.c) calls ml_open (midlevel.c) calls appledouble_open (resource.c) calls ll_open (lowlevel.c) calls afp_openfork (proto_fork.c).

    afp_openfork takes an unsigned char argument which is the desired fork access mode, i.e. a combination of AFP_OPENFORK_ALLOWREAD, AFP_OPENFORK_ALLOWWRITE, etc.

    ll_open takes an int argument (flags) which contains the desired UNIX access type and maps it to the AFP access mode. This is the code from ll_open:

         

      if (flags & O_RDONLY) aflags|=AFP_OPENFORK_ALLOWREAD;
            if (flags & O_WRONLY) aflags|=AFP_OPENFORK_ALLOWWRITE;        
            if (flags & O_RDWR) 
                    aflags |= (AFP_OPENFORK_ALLOWREAD | AFP_OPENFORK_ALLOWWRITE);
    

    This same flags argument is passed all the way down from the fuse_open call at the top of the hierarchy.

    But, for some reason, fuse_open tries to set flags to an _AFP access mode, when the rest of the coding implies it should be setting a UNIX access mode, with AFP mode not mapped until ll_open._

    Here's the whole of fuse_open with my modification of the call to ml_open. I only want to use afpfs to access remote files readonly so you will see I have hardwired flags to be O_RDONLY. With this mod I'm able to access readonly files from my Mac server as I want. (I don't know anything about fuse, but assume that the access mode should be picked up from the fuse structure in some way…).

    Hope this helps.

    static int fuse_open(const char *path, struct fuse_file_info *fi)
    {
            struct afp_file_info * fp ;
            int ret;
            struct afp_volume * volume=
                    (struct afp_volume *)
                    ((struct fuse_context *)(fuse_get_context()))->private_data;
            unsigned char flags = AFP_OPENFORK_ALLOWREAD;
            log_fuse_event(AFPFSD,LOG_DEBUG,
                    "*** Opening path %s\n",path);
           /* AME ret = ml_open(volume,path,flags,&fp); */
            ret = ml_open(volume,path,O_RDONLY,&fp);
            if (ret==0) 
                    fi->fh=(void *) fp;
            log_fuse_event(AFPFSD,LOG_DEBUG,"*** Return: %d\n",ret);
            return ret;
    }