Time Capsule compatibility

[rdmark]

With a Time Capsule A1470 3TB (fw 7.9.1) as the AFP server, xattr isn't working with the FUSE client. Only dirs without xattr are enumerated, files aren't. It's not possible to copy files onto the volume either.

The same works okay with afpcmd, which obviously ignores xattr.

server status details:

Server "AirPort Time Capsule"
    connection: 192.168.0.180:1536 (active)
    using AFP version: AFP3.3
    server UAMs: DHCAST128, DHX2 (used), Recon1
    login message: 
    type: TimeCapsule8,119
    signature: 4338364d57314843463948360069672d
    transmit delay: 0ms
    quantums: 262144(tx) 131072(rx)
    last request id: 1370 in queue: 0
    transfer: 55782(rx) 98118(tx)
    runt packets: 0
Volume "Data"
    id: 1
    attribs: 0x246c
    mounted: /Users/dmark/mnt
    did cache stats: 3 miss, 540 hit, 2 expired, 0 force removal
    uid/gid mapping: Login ids (0/0)
    Unix permissions: Yes

[NJRoadfan]

Connecting with AFP3.1 likely bypasses the issue. Is this using MacFUSE or something else (Linux) as a client? If so, the FPListxattr command returns the special Macintosh metadata (FinderInfo, Resource Fork), but can't actually read/write them with the state the client is in. Standard xattrs likely work fine. Also curious what a asip-status looks like for a Time Capsule.

[rdmark]

this is indeed macFUSE on macOS, I haven't tried on other FUSE systems yet.

forcing AFP 3.1 is a good idea for troubleshooting, but in this case it didn't make a difference, at surface level we get the same outcome, so this is either not xattr related or

afp_client mount --user **** --pass - --afpversion 31 x.x.x.x:Data /path/to/mnt
...
➜  ~ afp_client status mnt2
Server "AirPort Time Capsule"
    connection: x.x.x.x:1536 (active)
    using AFP version: AFP3.1
    server UAMs: DHCAST128, DHX2, Recon1, SRP (used)
    login message: 
    type: TimeCapsule8,119
    signature: 4338364d57314843463948360069672d
    transmit delay: 0ms
    quantums: 262144(tx) 131072(rx)
    last request id: 268 in queue: 0
    transfer: 10981(rx) 15875(tx)
    runt packets: 0
Volume "Data"
    id: 1
    attribs: 0x246c
    mounted: /path/to/mnt
    did cache stats: 0 miss, 0 hit, 0 expired, 0 force removal
    uid/gid mapping: Login ids (0/0)
    Unix permissions: Yes

[rdmark]

➜  ~ asip-status x.x.x.x
AFP reply from x.x.x.x:548 via IPv4
Flags: 1  Cmd: 3  ID: 57005
Reply: DSIGetStatus
Request ID: 57005
Machine type: TimeCapsule8,119
AFP versions: AFP3.3,AFP3.2,AFP3.1
UAMs: DHCAST128,DHX2,SRP,Recon1
Volume Icon & Mask: Yes
Flags: 
    SupportsCopyFile
    SupportsChgPwd
    SupportsServerMessages
    SupportsServerSignature
    SupportsTCP/IP
    SupportsSrvrNotifications
    SupportsReconnect
    SupportsOpenDirectory
    SupportsUTF8Servername
    SupportsUUIDs
    SupportsExtSleep
    SupportsSuperClient
Server name: airport-time-capsule
Signature:
43 38 36 4d 57 31 48 43 46 39 48 36 00 69 67 2d  C86MW1HCF9H6.ig-
                                                  
Network address: x.x.x.x:548 (IPv4 address and port)
Network address: [redacted]:548 (IPv6 address + port)
Network address: x.x.x.x (DNS address)
UTF8 Servername: AirPort Time Capsule

[NJRoadfan]

Based on a skim of xnu's VFS layer, if a file system that doesn't support extended attributes it is going to write them to ._ AppleDouble files. I would try mounting read-only to see if that changes anything. I'm sure the Time Capsule's firmware is not setup for a "weird" client that doesn't properly handle the AFP spec.