Shortcuts does not work with the File Provider

[i2h3]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Preconditions

1. You have the Nextcloud app installed.
2. You have at least one account signed in.
3. You have enabled the Nextcloud file provider in the iOS Files app and can browse the content.

Steps to reproduce

1. Open iOS Shortcuts app.
2. Create a new shortcut.
3. Add the "Append to Text File" action to your newly created shortcut.
4. Select the root folder of the Nextcloud file provider domain as the location variable of the action.

Expected behaviour

The shortcuts action variable should be updated with the name of the file provider domain.

Actual behaviour

1. The Shortcuts app freezes and must be forced to relaunch.
2. The variable value change was not applied to the action.

Notes

• I filed this as a distinct bug report to fix a specific problem instead of vaguely tackling the feature ideas described in #662.
• By default it should be safe to expect for this to work. The file provider framework is there to abstract external storage services and integrate them into the iOS Files. For the Shortcuts app, it is transparent which underlying storage is used and it should not matter.
• This is issue is a lead and not the actual pinpointed problem yet.
• As mentioned in the feature request #662, this problem likely is the cause why the iOS Shortcuts app does not work with the Nextcloud file provider.
• Selecting a subfolder in the Nextcloud file provider domain does not cause the Shortcuts app to crash. It always results in an error of the action that the file cannot be accessed no matter the selected location and entered file path.
• Based on past experience with file providers, I suspect that there might be something not 100% correct with the returned metadata when the root container is requested by the system.

Logs

Not applicable.

Reasoning or why should it be changed/implemented?

As described in #662, this is the show stopper for the whole Shortcuts app integration. This should work and other services actually do work with the steps to reproduce above. Once fixed, it will open up the vast possibilities for automation which come for free with iOS (or even additional ones provided by third-party apps). Also, this is a requirement for implementing custom Shortcuts actions for service specific tasks like the creation of a Nextcloud Talk conversation.

Environment data

iOS version: e.g. iOS 18.2 (though it occurred already on previous iOS 18 releases)

Nextcloud iOS app version: see More > Settings

Server operating system: Ubuntu Server 24.04 LTS

Web server: Whatever latest Nextcloud All-in-One uses

Database: Whatever latest Nextcloud All-in-One uses

PHP version: Whatever latest Nextcloud All-in-One uses

Nextcloud version: Nextcloud Hub 9 (30.0.4)

Examples

Here is a screenshot of an iPad Simulator demonstrating the test shortcut in split view with the Files app.

[i2h3]

OX Drive

I reproduced this problem with the current OX Drive release on the App Store as a comparison. I will also check with other file providers such as ownCloud and the big brands soon. Maybe not our file provider implementation is the problem.

[i2h3]

Dropbox

With Dropbox, root folder and subfolder work without any problems.

The root folder was labeled as "Privat" in the Shortcuts action argument in my case.

[i2h3]

Google Drive

Like the other apps, I installed the app, signed in, went to the iOS files app, activated the file provider and had a first look into the account there. Just like Dropbox, I did not have any content in there because I did not use the service previously. iOS Files showed "[…] is empty".

Switching to the Shortcuts app, I tapped on the folder argument and browsed for the Google Drive root folder. Strangely, I cannot open it as the location. The open button in the iOS sheet of the Shortcuts app is disabled. I cancel the selection. I switch back to the iOS Files app and create an empty "Subfolder". I switch back to the Shortcuts app, browse for a folder as the folder argument again, go to the Google Drive root folder and suddenly iOS shows that the content is unavailable due to an unknown error. Retrying does not help. Even in the iOS Files app itself that happens. Only after opening the Google Drive app and synchronizing by pull-to-refresh this error is resolved.

Now I select the Google Drive root folder as the argument for the Shortcuts action and it freezes like with Nextcloud and OX Drive. Afterwards I see the unavailable content error again. Relaunching the Shortcuts app to select the subfolder in Google Drive as the action argument, I cannot do so because the folder selection sheet keeps its open button disabled. Even after manually adding the placeholder file in the Google Drive app it still is disabled. So something really appears broken here.

[i2h3]

OneDrive

Strangely, OneDrive behaves similar. The root folder was not available for selection Shortcuts after browsing it in Files. Even after a device reboot. The root folder apparently is not writable. I copied a meme image (Y U NO) from iCloud drive into the files subfolders in the iOS Files app. That subfolder still is not available for selection in Shortcuts.

[i2h3]

ownCloud

I pasted the same meme image into ownCloud which worked fine. But the file provider extension of ownCloud apparently runs into an error when deleting the file afterwards (communication with a helper application failed, as reported by iOS, familiar error message from my previous job). Anyway, I cannot select any location in ownCloud either in iOS Shortcuts.

[i2h3]

I filed feedback FB16312015 at Apple that the Shortcuts app apparently does not work well with third-party providers and I cannot figure out why.

[i2h3]

I received a response to my filed feedback from Apple. They allegedly implement significant changes since this problem was filed and asked me to verify with the new iOS 18.5 beta 4.

I downloaded Xcode 16.4 beta (16F1t) and ran our Nextcloud 6.6.1 app in the iOS 18.5 Simulator coming with the Xcode release.

Unfortunately, it still does not work. Selecting the root directory of the Nextcloud file provider lets the iOS shortcuts app freeze completely and only a forced quit can make it responsive again after relaunch. So I need to pick "Documents" as the location in the action. Trying different file paths like "3261.log" or "/3261.log" or "/Documents/3261.log" did not help. When choosing "On My iPhone" and "/3261.log" it works fine. As one might expect, everything works fine when using iCloud Drive, too.

I always receive the error alert titled "Invalid file path" with the message "The provided file path must be contained within the directory."

Filtering the Simulator logs in macOS' Console.app for "File-Provider-Extension" as used in the bundle identifier of the app's file provider extension target I found one particularly interesting message among a lot of debug output:

fehler fileproviderd com.apple.FileProvider it.twsweb.Nextcloud.File-Provider-Extension/N{35}r 11:15:25.324208+0200 [ERROR] ❌ no item provided for <GroupContainers>/F608A3FC-582A-4801-BCC3-DF1C1244B338/F{19}e/N{39}r/r{2}t; NSError: FP -1005 "The file doesn’t exist." UserInfo={NSFileProviderErrorItemName=root, NSUserStringVariant=Open, NSFilePath=/U{3}s/i{1}a/L{5}y/D{7}r/C{11}r/D{5}s/E{34}7/d{2}a/C{8}s/S{4}d/A{6}p/F{34}8/F{19}e/N{39}r/r{2}t} }

So, apparently, maybe, the file provider extension is (not) providing as expected. This might be a lead which I cannot follow up on now.

[i2h3]

@marinofaggiana @tobiasKaminsky At least I figured out how to prevent the iOS Shortcuts app from freezing (see 3261-directory-placeholders branch). We are implementing some file provider extension calls wrong. In example placeholder files are meant to be provided for actual file items only, not for directories. The Shortcuts workflow then also works and appends text to a file but apparently not one managed by our extension but some other. There also is no complaint about the file not being found. However, our extension apparently is not informed about the changed content. I need to focus on more important matters now.