Setting URLResourceKey.fileSecurityKey raises error on some systems

Question

Created Apr ’23

Replies 1

Boosts 0

Participants 2

A customer reported that when my app creates directories on their NAS, an error is shown. With their cooperation I boiled the source of the error down to setting URLResourceKey.fileSecurityKey on the directory URL, or setting any of FileAttributeKey.groupOwnerAccountID, .groupOwnerAccountName, .ownerAccountID or .ownerAccountName with FileManager.

I thought that maybe URLResourceKey.volumeSupportsExtendedSecurityKey would allow me to determine in advance if setting any of these attributes works, but it seems that the result is false on one of my exFAT drives which doesn't yield any error when setting any of the attributes. I don't even know what "extended security" means in this case, and it doesn't seem to be documented. Should I rely on URLResourceKey.volumeSupportsExtendedSecurityKey?

I tried running chown -vv myusername:admin on a file on that exFAT drive: even if the output includes the text 501:20 -> 501:80, which I assume means that the group should have been changed to admin, running the command again yields the exact same output and running stat shows that the group is still staff.

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’23

At a conceptual level, there’s no way to preflight the behaviour of operations you do on a network volume because ultimately the file server decides what is or isn’t allowed.

However, .fileSecurityKey should behave the same as the underlying BSD-level calls. If, for example, you use it to change the owner of a file, that should work if the BSD chown call works. What I usually do in situations like this is to add a temporary call to chown to see if that works. If it exhibits different behaviour than .fileSecurityKey, that’s worth investigating that. OTOH, if the two APIs behave the same, that rules out a Foundation-level issue and it’s time to dig deeper into the stack.

I tried running chown -vv myusername:admin on a file on that exFAT drive

exFAT does not support users and groups and so everything gets mapped to the _unknown user which brings in a whole pile of complexity. If you want to test this stuff:

Test on a local APFS or HFS Plus volume with ownership enabled, like the boot volume.
Test on a network volume that uses the same network file system as your user (probably SMB).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1