0

I have a number of files synced with Microsoft's OneDrive. Recently, I found all of the files were unopenable with permission denied, even though I apparently had full access:

% ls -l notes/centos
-rwxrwxrwx@ 1 norman  admin  31644 27 Apr 18:33 notes/centos*
% cat notes/centos
cat: notes/centos: Permission denied

Those files have extended attributes, so we take a look at those:

% ls -l@ centos
-rwxrwxrwx@ 1 norman  admin  31644 27 Apr 18:33 centos*
        com.apple.LaunchServices.OpenWith     118 
        com.apple.fileutil.PlaceholderData    384 
        com.apple.metadata:com_apple_backup_excludeItem    61 
        com.microsoft.OneDrive.RecallOnOpen     0 

That's a little unexpected, but none of those are obviously ACLs, for example.

I then realised that the OneDrive client needed to be re-authenticated. So I did so, and

% ls -l@ centos
-rwxrwxrwx@ 1 norman  admin  31644 27 Apr 18:33 centos*
        com.apple.fileutil.PlaceholderData    384 
% cat centos
blah blah...

At this point I'm puzzled. What's happening here? I can't find anything sensible on OneDrive.RecallOnOpen, except that it seems to be some Windows registry property (?). The numbers 118 and 384 are, rather suggestively and possibly coincidentally, 166 and 600 in octal, and thus look a little like (weird) permissions bits. But the names of the attributes don't make any sense in that context.

It's clear that OneDrive isn't a very good macOS citizen (witness the 777 file permissions that everything ends up with), but this is disturbing.

Where are extended attributes documented?

I don't right now have a problem, because with OneDrive re-authenticated I can see the files I expect, but this is clearly a bit of the 11.x permissions model that is far from the traditional unix one, and I don't like being this ignorant.

This is on 11.5.2, and an APFS filesystem.

(I wanted to add a onedrive tag, but I don't have the reputation on this SE site to do so)


Edited to add:

...aaaand it's happened again. It's clearly something to do with needing to re-authenticate the OneDrive client, so I know what to do to ‘fix’ this, but I'd still like to know what's actually going on here.

I have another ‘permission denied’ file:

% cat stuff/wireless-pins.txt 
cat: stuff/wireless-pins.txt: Permission denied
% ls -l@eO stuff/wireless-pins.txt
-rwxrwxrwx@ 1 norman  admin  - 46 27 Apr 18:33 stuff/wireless-pins.txt*
    com.apple.LaunchServices.OpenWith   118 
    com.apple.fileutil.PlaceholderData  384 
    com.apple.metadata:com_apple_backup_excludeItem 61 
    com.microsoft.OneDrive.RecallOnOpen  0 
% xattr -l stuff/wireless-pins.txt
com.apple.LaunchServices.OpenWith:
00000000  62 70 6C 69 73 74 30 30 D2 01 02 03 04 57 76 65  |bplist00.....Wve|
00000010  72 73 69 6F 6E 5F 10 10 62 75 6E 64 6C 65 69 64  |rsion_..bundleid|
00000020  65 6E 74 69 66 69 65 72 10 00 5F 10 24 63 6F 6D  |entifier.._.$com|
00000030  2E 6D 69 63 72 6F 73 6F 66 74 2E 4F 6E 65 44 72  |.microsoft.OneDr|
00000040  69 76 65 2E 44 6F 77 6E 6C 6F 61 64 41 6E 64 47  |ive.DownloadAndG|
00000050  6F 08 0D 15 28 2A 00 00 00 00 00 00 01 01 00 00  |o...(*..........|
00000060  00 00 00 00 00 05 00 00 00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 51                                |.....Q|
00000076
....

I've shown the contents of the OpenWith attribute, since that hints at some facility where this file will be downloaded before being shown. OK, so OneDrive is doing something funky about syncing things. I'm sure that's very clever, but I'd like to know which subsystem it is – the filesystem, the OS, the OneDrive app? – that's producing a permission-denied error.

The Apple docs on LaunchServices attributes is the nearest I can find to Apple documentation of this (and it tells me nothing); a third-party note on this attribute suggests ‘sets a custom app to open a file’, which is entirely unsurprising, but doesn't suggest there would be a permissions issue if opening a file from the shell.

The file that I had problems with above, is currently fine, but with a very different set of attributes:

% head -2 notes/centos               
CentOS installations
====================
% ls -l@eO notes/centos
-rwxrwxrwx@ 1 norman  admin  - 31644 27 Apr 18:33 notes/centos*
    com.apple.fileutil.PlaceholderData    384 
    com.apple.lastuseddate#PS      16 

Once I reauthenticate, I get, briefly,

% ls -le@O stuff/wireless-pins.txt
-rwxrwxrwx@ 1 norman  admin  - 46 27 Apr 18:33 stuff/wireless-pins.txt*
    com.apple.FinderInfo    32 
    com.apple.LaunchServices.OpenWith   118 
    com.apple.ResourceFork  1840 
    com.apple.fileutil.PlaceholderData  384 
    com.apple.metadata:com_apple_backup_excludeItem 61 
    com.microsoft.OneDrive.RecallOnOpen  0 

and then, moments later,

% ls -le@O stuff/wireless-pins.txt
-rwxrwxrwx@ 1 norman  admin  - 46 27 Apr 18:33 stuff/wireless-pins.txt*
    com.apple.fileutil.PlaceholderData  384 

...and the file is readable again. I could scream.

I don't think I like OneDrive very much.

2
  • Extended attributes shouldn't affect file permissions; check for access control lists and file flags with ls -leO. BTW, the numbers after those xattr names are the number of bytes of data in the xattr; to see the actual data, use xattr -l. Sep 1 at 17:24
  • Aha!: I've no idea why I didn't specifically look for ACLs in the manpage – the ACL on that file would have been useful to see (I semi-automatically tried the SELinux getfacl command and when that didn't work, put macOS ACLs into a different part of my head). Unfortunately (sort-of) I no longer have the permissions problem since I reauthenticated, but if the problem comes back, I'll try to remember to update this question. Thanks, @GordonDavisson, for the reminder about xattr – I should have remembered that. Sep 1 at 18:56

You must log in to answer this question.

Browse other questions tagged .