UIDocumentPickerViewController does not allow picking folders on connected servers on iOS26

Question

Created 4d

Replies 5

Boosts 0

Participants 3

Hey there,

I have an app that allows picking any folder via UIDocumentPickerViewController. Up until iOS18 users were able to pick folders from connected servers (servers connected in the Files app) as well.

On iOS26, the picker allows for browsing into the connected servers, but the Select button is greyed out and does nothing when tapped.

Is this a known issue? This breaks the whole premise of my file syncronization application.

Answered by DTS Engineer in 865632022

Absolutely, although it is not much of a test project: https://github.com/martonfarago/documentPickerTest Using this, I can pick a folder on an SMB share just fine under 18.7 but cannot under 26.1.

I've downloaded your sample project and, with two exceptions, I'm not able to replicate what you're describing. The two exceptions I found were:

When you initially navigate into a server, the list of shared returned can't be "opened". This happens because that list is artificially generated and doesn't actually exist in the file system.
I'm not sure what the exact criteria we're applying is, but I think what's happening is that we're only enabling "Open" in directories you can write to.

I'm not sure if #2 is new behavior or not, as I don't have an iOS 18 device handy to test it with, nor have I been able to find a specific bug/change that would have changed the behavior. So, a few points here:

Is the share you're testing with coming from macOS? If it's not macOS, what is it? Note that one of the issues here is that some NAS boxes are running particularly old versions of smb, which can end up creating odd edge cases.
Make sure you're specifically testing a location you know to be writable. As a note on that point, make sure you unmount/mount the share whenever you change permissions (or other state) on the server. There is significant caching throughout the API stack, and you want to make sure that state is cleared when you're testing.

In terms of #2, if you haven't already, then please file a bug on this and post the number back here. I'm not sure what the default behavior should be, but there should certainly be a way that your app can get access to directories it can't write to.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

3d

Can you reproduce this in a small test project?

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

0

Answer 2

interferenc OP

3d

Absolutely, although it is not much of a test project: https://github.com/martonfarago/documentPickerTest

Using this I can pick a folder on an SMB share just fine under 18.7 but can not under 26.1.

Thanks for the help.

0

Answer 3

DTS Engineer OP

Apple

2d

Weird.

I’m not aware of changes in the space. I’m gonna chat with some colleagues about this and get back to you.

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

0

Answer 4

DTS Engineer OP

Apple

1d

Accepted Answer

Absolutely, although it is not much of a test project: https://github.com/martonfarago/documentPickerTest Using this, I can pick a folder on an SMB share just fine under 18.7 but cannot under 26.1.

I've downloaded your sample project and, with two exceptions, I'm not able to replicate what you're describing. The two exceptions I found were:

When you initially navigate into a server, the list of shared returned can't be "opened". This happens because that list is artificially generated and doesn't actually exist in the file system.
I'm not sure what the exact criteria we're applying is, but I think what's happening is that we're only enabling "Open" in directories you can write to.

I'm not sure if #2 is new behavior or not, as I don't have an iOS 18 device handy to test it with, nor have I been able to find a specific bug/change that would have changed the behavior. So, a few points here:

Is the share you're testing with coming from macOS? If it's not macOS, what is it? Note that one of the issues here is that some NAS boxes are running particularly old versions of smb, which can end up creating odd edge cases.
Make sure you're specifically testing a location you know to be writable. As a note on that point, make sure you unmount/mount the share whenever you change permissions (or other state) on the server. There is significant caching throughout the API stack, and you want to make sure that state is cleared when you're testing.

In terms of #2, if you haven't already, then please file a bug on this and post the number back here. I'm not sure what the default behavior should be, but there should certainly be a way that your app can get access to directories it can't write to.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 5

interferenc OP

1d

Hey Kevin,

Thanks for looking into this.

For 1, you are right and I did not expect to be able to "pick" the list of shares on a server.

For 2, you are absolutely right. I managed to change the server configuration to show up as writable for iOS, after which I was able to pick the folders from iOS26.1.

This is new behavior for sure as I can consistently pick read-only folders on iOS 18. I do agree that this should be the expected behavior, I should be able to work with read-only folders and files too.

I just filed a bug report about this here: FB20997701

As a side-note, my personal folders were always configured to be writable and they are indeed writable from linux and macOS clients. Only iOS clients started to think they are read only and only after the iOS18 update, see this thread: https://discussions.apple.com/thread/255775451?sortBy=rank

Adding vfs objects = catia fruit streams_xattr to my share's configuration made them appear writable from iOS, and as such pickable too.

0