Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DBDownloadUrlTask permission issue 513 under iOS 10.3 #125

Closed
ghost opened this issue Apr 5, 2017 · 15 comments
Closed

DBDownloadUrlTask permission issue 513 under iOS 10.3 #125

ghost opened this issue Apr 5, 2017 · 15 comments

Comments

@ghost
Copy link

ghost commented Apr 5, 2017

After setting the responseBlock on the following download task:

DBDownloadUrlTask *downloadTask = [self.dropboxClient.filesRoutes downloadUrl:originPathOfFileToDownload overwrite:YES destination:destinationURL];

I am getting the error message:

NSError = "Error Domain=NSCocoaErrorDomain Code=513 "\U201eCFNetworkDownload_usQ10T.tmp\U201c konnte nicht bewegt werden, da du nicht \U00fcber die erforderlichen Zugriffsrechte f\U00fcr \U201etmp\U201c verf\U00fcgst." UserInfo={NSSourceFilePathErrorKey=/var/mobile/Library/Caches/com.apple.nsurlsessiond/Downloads/com.-----.——/CFNetworkDownload_usQ10T.tmp, NSUserStringVariant=(\n Move\n), NSDestinationFilePath=/private/var/mobile/Containers/Data/Application/03757827-B45C-4CFD-9F34-DFE20371E541/tmp/Pepsi.jpg, NSFilePath=/var/mobile/Library/Caches/com.apple.nsurlsessiond/Downloads/com.-----.-----/CFNetworkDownload_usQ10T.tmp, NSUnderlyingError=0x17045a340 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}"

It works for us on iPad with iOS 9.3.5/iPad2 and iOS 10.2/iPad Air 2 but it fails on an iOS 10.3/iPad Pro 12.9". This morning I made a pod update to version 3.0.10 but this has not resolved the problem.

I also followed the proposals from the issue: #60 with the following implementation:

DBTransportDefaultConfig *transportConfiguration = [[DBTransportDefaultConfig alloc] initWithAppKey:DROPBOX_APP_KEY appSecret:DROPBOX_APP_SECRET userAgent:nil asMemberId:nil delegateQueue:nil forceForegroundSession:NO sharedContainerIdentifier:[NSBundle mainBundle].bundleIdentifier];
[DBClientsManager setupWithTransportConfig:transportConfiguration];

But the problem still exists.
Thank you very much in advance for your great support and for suggestions…

@scobbe
Copy link
Contributor

scobbe commented Apr 5, 2017

@Sipeso: Thanks for reaching out. I'm looking into the issue now!

@guidedways
Copy link

@Sipeso silly question but is your app setup for App Groups under Capabilities? You need to assign it the same container Id that you have specified there. It won't work, I think, otherwise. I had the same issue but I'm not experiencing anything since my app uses App Groups on both the Mac and iOS.

@guidedways
Copy link

@Sipeso can you also try with forceForegroundSession: YES?

@scobbe
Copy link
Contributor

scobbe commented Apr 5, 2017

@guidedways: Thanks for the helpful suggestions. I'm still struggling to understand why this would be a 513 permissions issue. When you experienced this issue, did you experience it when building for multiple device-types on the same simulator? Did you ever experience this on a physical device?

@Sipeso: When you experience this issue was it on a physical device or on the simulator? Do you experience the same issue on iOS 10.3/iPad Pro 12.9 after going to Simulator > Reset Content and Settings...?

@guidedways
Copy link

@scobbe I actually never tested it on a simulator - I've learned never to really trust the simulator so all my tests were on real devices (an iPhone 10.3 and iPad 10.0) - so I can confirm I was seeing this on both 10.0 and 10.3

@guidedways
Copy link

@scobbe for what it's worth, I don't understand why it fails for some and why it doesn't for others.. plus the 513 error doesn't make sense. Most certainly a NSURLSession bug (given v1 didn't use NSURLSession and v2 does - and we never saw these in v1). I've just recently ported from v1 to v2 and started seeing this immediately. Devices still using v1 did not.

@scobbe
Copy link
Contributor

scobbe commented Apr 5, 2017

@guidedways: Thanks for the perspective! This is helpful.

@ghost
Copy link
Author

ghost commented Apr 6, 2017

Dear all,
thank you very much for your swift and useful responses.
I was able to resolve it based on guidedways hint 'forceForegroundSession: YES'.

Now it works on all physically used devices and iOS installation (as mentioned above) with the following DBClientsManager configuration:
DBTransportDefaultConfig *transportConfiguration = [[DBTransportDefaultConfig alloc] initWithAppKey:DROPBOX_APP_KEY
forceForegroundSession:YES];

In our case it definitely does not work under iOS 10.3/iPad Pro 12.9" when forceForegroundSession is set to 'NO'.

@quidedways: Under the Capabilities 'App Groups' are switched off, we don't need it.
@scobbe: All mentioned iPad and iOS tests are done on physically devices during Xcode 8.3 connection and without Xcode connection.

Fyi: Our latest app store version runs still the Dropbox API v1 (Core API). That is why we are currently migrating to v2 and preparing the app for the next app store release.
So far, all downloads and uploads from and to Dropbox work when we link Dropbox in the current app store version (Dropbox v1) and overwrite it with the next app version which uses Dropbox v2. We have not yet implemented 'checkAndPerformV1TokenMigration' and currently see no reason why to do that.

So, thank you very much again for all your help.
Please let me know if there is something open on that issue otherwise I am closing it.

@guidedways
Copy link

@Sipeso that's great! Yeah I suspect background NSURLSession is at fault somehow. By the way, if your apps are using v1 already, you will in fact need checkAndPerformV1TokenMigration. This will ensure your users don't have to link with Dropbox again and they won't lose the current delta tokens etc. If you don't do this, upon updating your app your users will complain that the app isn't linked to dropbox anymore and perhaps linking with Dropbox may be destructive (i.e. they may need to painfully download a lot of meta data / files all over again). In our case checkAndPerformV1TokenMigration helps since it silently and gracefully moves the V1 tokens over to V2 without the users having to re-link and re-sync.

@ghost
Copy link
Author

ghost commented Apr 7, 2017

@guidedways Thank you very much for your great support for solving our issue and your advice concerning the checkAndPerformV1TokenMigration (what we are implementing right now).

@ghost ghost closed this as completed Apr 7, 2017
@alebaldi
Copy link

alebaldi commented May 4, 2017

I have same problem with iOS 10.3 on iPhone and Dropbox SDK (last version). I set forceForegroundSession to YES but no result... sometimes I have no error... but more frequently my download fails... and error is criptic...
If I use downloadData instead of downloadUrl I have no error but NSData is emtpy (no data)... so my download fails...

@scobbe
Copy link
Contributor

scobbe commented May 4, 2017

@alebaldi: I think I might have determined with the issue is. Please try updating to the latest version of the SDK, v3.0.18, and see if that fixes your issue.

@alebaldi
Copy link

alebaldi commented May 5, 2017

@scobbe with last version, 3.0.18, it's all ok. I have three App, and all Apps now it's all ok. Thank you very much! ;-)

@shoaibhassanWhizpool
Copy link

shoaibhassanWhizpool commented Aug 29, 2017

@scobbe i am also facing same issue.
when i call downloadUrl with connected wifi.Nothing happens.its does't move to completion block or progress block and stucks there..i am using cocoa Pods version 3.2.0 and testing on iPhone 6 with iOS 10.3.
Any solution?

@greg-db
Copy link
Contributor

greg-db commented Aug 29, 2017

@shoaibhassanWhizpool It sounds like you may be running in to a somewhat different issue. The issue reported here was for a specific error, but you said you're not getting anything.

Please open a new issue with the details of the issue you're seeing (i.e., steps to reproduce the issue, relevant code, etc.). Thanks

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants