Slug-V
commented
4 years ago I'm facing this problem with iOS 13.7.
Closed keepassium closed 2 years ago
Slug-V
commented
4 years ago I'm facing this problem with iOS 13.7.
keepassium
commented
4 years ago @Slug-V, can you please describe your specific symptoms in more details? (which cloud, how often, any other related info) Thanks!
Slug-V
commented
4 years ago okay,
iOS&iPhone: iOS13.7 on iPhone X(64GB) KeePassium: ver.1.17.74 with Premium subscription cloud: Nextcloud ver.19.0.3 with iOS App ver.3.0.8(both latest) how often: everytime (Files linked to KeePassium remain available only for several minutes. After that, any attempt to access a linked file results "ファイルが存在しません。", means "The file doesn't exist.")
diag info:
-0.001 (I) AppDelegate.swift:47 application(_:didFinishLaunchingWithOptions:) KeePassium v1.17.74 (iPhone, iOS 13.7)
0.057 (I) PremiumManager.swift:204 updateStatus(allowSubscriptionExpiration:) Premium subscription status changed [was: initialGracePeriod, now: subscribed]
0.239 (I) ReceiptAnalyzer.swift:181 analyzeSubscriptions(_:) Subscription fallback date: 2020-08-17
0.247 (D) FileKeeper.swift:882 deleteExpiredBackupFiles() Will perform backup maintenance
0.252 (I) FileKeeper.swift:884 deleteExpiredBackupFiles() Backup maintenance completed
0.403 (I) Watchdog.swift:248 engageAppLock() Engaging App Lock
0.863 (E) FileAccessError.swift:118 make(from:fileProvider:) Failed to access the file [fileProvider: it.twsweb.Nextcloud.File-Provider-Extension, systemError: Error Domain=NSFileProviderErrorDomain Code=-1005 "ファイルが存在しません。" UserInfo={NSFileProviderErrorNonExistentItemIdentifier=00016959ocxao1j9qcxc}]
0.869 (W) FileInfoReloader.swift:58 getInfo(for:update:completion:) Failed to get file info [reason: ファイルが存在しません。]
1.893 (I) Watchdog.swift:248 engageAppLock() Engaging App Lock
3.056 (E) UnlockDatabaseVC.swift:270 showErrorMessage(_:details:suggestion:haptics:) ファイルが存在しません。
244.552 (D) Watchdog.swift:125 willResignActive() Going to background: App Lock engaged
keepassium
commented
4 years ago iOS&iPhone: iOS13.7 on iPhone X(64GB) KeePassium: ver.1.17.74 with Premium subscription cloud: Nextcloud ver.19.0.3 with iOS App ver.3.0.8(both latest) how often: everytime (Files linked to KeePassium remain available only for several minutes. After that, any attempt to access a linked file results "ファイルが存在しません。", means "The file doesn't exist.")
Well, Nextcloud is not exactly the most stable app... As such, I would not extend the scope of this issue to iOS 13.7 only because something is wrong with Nextcloud sync — most likely, this would be an issue with Nextcloud itself.
Slug-V
commented
4 years ago Thank you @keepassium. Today, my KeePassium suddenly stopped reproducing this behavior. Now everything works fine. (It's curious. I confirmed that this problem doesn't disappear for several weeks with Nextcloud-iOS 3.0.6-3.0.8.)
I'll stay using KeePassium and make a new issue to nextcloud/ios or nextcloud/server if rehappened. This was unrelated to iOS but Nextcloud...I apologize for my thoughtless.
keepassium
commented
4 years ago No worries, @Slug-V. Good luck with Nextcloud!
MadWalnut
commented
4 years ago I have this issue, it appears randomly for me. Sometimes it works, sometimes it doesn't (could match the claim that it happens after a few hours though - just not every time?). I have never seen it while opening Keepassium directly, only when trying to use autofill (although I must say I mostly use Keepassium with autofill only). I then get the message "The file couldn’t be opened because you don’t have permission to view it.". After a few minutes I can retry and it will just work again. This happened to me about 5 times now after updating to iOS 14. Never had the issue on iOS 13.
iPhone XS with iOS 14.0.1 KeePassium 1.17.74 Google Drive 4.2020.38202
I also noticed it sometimes can't find my keyfile as well (stored on local storage). Gives me an error. I can manually re-add it though (same location without modifying the keyfile). This happend twice out of the ~5 times I got the permission error.
I forgot to take a screenshot / copy the log the last times this happened and now it's not happening anymore (ofc...), sorry.
keepassium
commented
4 years ago @MadWalnut , thank you for the input!
I also noticed it sometimes can't find my keyfile as well (stored on local storage).
Yeah, that's because AutoFill uses references for all files, both databases and key files. Since the system runs AutoFill as a separate process, this process has its own sandbox and does not have access to access KeePassium's sandbox (where the key files are stored). So AutoFill has to use file references to access even local storage — hence the permission error even for local storage...
This happend twice out of the ~5 times I got the permission error.
So it seems that storage providers refuse access randomly but not simultaneously. That's interesting...
I forgot to take a screenshot / copy the log the last times this happened and now it's not happening anymore (ofc...), sorry.
Hey, this is a great workaround! :)
1) Experience an issue and start preparing a bug report. 2) Wait for the bug to repeat, in order to take screenshots. 3) ...Out of spite, the bug will never happen again :)
MadWalnut
commented
4 years ago This time I got the issue on my iPad and I remembered to take screenshots and logs.
iPad Gen. 6 with iOS 14.0 (not 14.0.1 yet like my iPhone above) KeePassium 1.17.74 Google Drive 4.2020.38202
The database is stored in Google Drive, the keyfile is stored locally.
Attempt to open the database:
-0.000 (I) MainCoordinator.swift:54 init(rootController:) KeePassium AutoFill v1.17.74 (iPad, iOS 14.0)
0.612 (I) PremiumManager.swift:204 updateStatus(allowSubscriptionExpiration:) Premium subscription status changed [was: initialGracePeriod, now: freeLightUse]
0.636 (D) FileKeeper.swift:882 deleteExpiredBackupFiles() Will perform backup maintenance
0.639 (I) FileKeeper.swift:884 deleteExpiredBackupFiles() Backup maintenance completed
0.679 (I) DatabaseManager.swift:172 _loadDatabase(dbRef:compositeKey:) Will load database
0.707 (E) FileAccessError.swift:118 make(from:fileProvider:) Failed to access the file [fileProvider: com.google.Drive.FileProviderExtension, systemError: Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it."]
0.707 (E) FileAccessError.swift:118 make(from:fileProvider:) Failed to access the file [fileProvider: com.google.Drive.FileProviderExtension, systemError: Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it."]
0.730 (W) FileInfoReloader.swift:58 getInfo(for:update:completion:) Failed to get file info [reason: The file couldn’t be opened because you don’t have permission to view it.]
0.730 (E) DatabaseManager.swift:723 onDatabaseURLResolveError(_:) Failed to resolve database URL reference [error: The file couldn’t be opened because you don’t have permission to view it.]
0.737 (E) DatabaseUnlockerVC.swift:98 showErrorMessage(_:reason:suggestion:haptics:) Cannot find database file
The file couldn’t be opened because you don’t have permission to view it.Attempt to access the keyfile:
-0.000 (I) MainCoordinator.swift:54 init(rootController:) KeePassium AutoFill v1.17.74 (iPad, iOS 14.0)
0.656 (I) PremiumManager.swift:204 updateStatus(allowSubscriptionExpiration:) Premium subscription status changed [was: initialGracePeriod, now: freeLightUse]
0.661 (I) Watchdog.swift:248 engageAppLock() Engaging App Lock
0.703 (D) MainCoordinator.swift:821 showBiometricAuth() Biometric auth: showing request
0.713 (D) FileKeeper.swift:882 deleteExpiredBackupFiles() Will perform backup maintenance
0.715 (I) FileKeeper.swift:884 deleteExpiredBackupFiles() Backup maintenance completed
0.728 (I) DatabaseManager.swift:172 _loadDatabase(dbRef:compositeKey:) Will load database
1.045 (E) FileAccessError.swift:118 make(from:fileProvider:) Failed to access the file [fileProvider: com.google.Drive.FileProviderExtension, systemError: Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it."]
1.049 (E) DatabaseManager.swift:723 onDatabaseURLResolveError(_:) Failed to resolve database URL reference [error: The file couldn’t be opened because you don’t have permission to view it.]
1.052 (E) DatabaseUnlockerVC.swift:98 showErrorMessage(_:reason:suggestion:haptics:) Cannot find database file
The file couldn’t be opened because you don’t have permission to view it.
2.329 (I) MainCoordinator.swift:826 showBiometricAuth() Biometric auth successful
4.296 (E) FileAccessError.swift:118 make(from:fileProvider:) Failed to access the file [fileProvider: com.apple.FileProvider.LocalStorage, systemError: Error Domain=NSCocoaErrorDomain Code=4 "The file doesn’t exist."]
4.337 (W) FileInfoReloader.swift:58 getInfo(for:update:completion:) Failed to get file info [reason: The file doesn’t exist.]
13.122 (E) FileAccessError.swift:118 make(from:fileProvider:) Failed to access the file [fileProvider: com.apple.FileProvider.LocalStorage, systemError: Error Domain=NSCocoaErrorDomain Code=4 "The file doesn’t exist."]
19.789 (W) DatabaseUnlockerVC.swift:232 setKeyFile(urlRef:) Key file error: The file doesn’t exist.
19.790 (E) DatabaseUnlockerVC.swift:98 showErrorMessage(_:reason:suggestion:haptics:) Key file error: The file doesn’t exist.Screenshots: Database 1 Database 2 Keyfile 1 Keyfile 2 Keyfile 3
keepassium
commented
4 years ago Thanks, @MadWalnut. Since there are no underlying errors, I assume the access attempt was immediately refused by the system and never made it to the file provider. Did these error happen on two separate occasions or simultaneously?
MadWalnut
commented
4 years ago @keepassium The two errors appeared simultaneously.
Although just now as I was trying to sign into GitHub on my iPhone to write this comment, the error re-appeared (via autofill). This time the keyfile could be found, but not the database. After I got that error multiple times (I tried a few times), I opened KeePassium manually to get the password and that worked perfectly without an error just seconds later. Right after that I tried again with autofill and the error was gone. Not sure if the error went away by successfully getting the file directly with the app or if that was a coincidence.
I’ll see if this scenario repeats itself or maybe someone else can confirm. Not a real workaround though, as the error can also appear when opening the app without autofill.
keepassium
commented
4 years ago Oh, so the error can also randomly disappear. Thanks, @MadWalnut. This gets curiouser and curiouser...
LetMeR00t
commented
4 years ago Hi @keepassium, I would like to share with you an issue I had today on my side. I've changed my way to backup my keepass using Google Drive. Everything runs perfectly until now ... The context is :
If I change something from the smartphone, there is no issue. But, if I try to change something on my PC (and then wait for the synchronization etc.), I faced the same kind of issue that you are describing here :
I'm on an iPhone using iOS 14. Is this issue can be linked to what you describe here ? I would like to precise that the file is well synchronized on my phone.
Thank you
keepassium
commented
4 years ago @LetMeR00t , thanks for the feedback. However, your issue is different:
1) it can be reliably reproduced (every time after the database is edited on the PC), 2) it is quite typical for the case when the database file is not rewritten, but replaced: the original database file is deleted, and GDrive saves the updated database as a new file (at the same location, with the same name). For a human eye, it looks like the original file was updated. However, for iOS this is a different file. So KeePassium's reference to the original database does not work — it reports that the file was deleted ("Error Domain=trash").
The only time I saw this error before was related to https://github.com/astrada/google-drive-ocamlfuse/issues/659
As a solution, try toggling the safe saving option on your PC:
KeePass 2: Tools → Options → Advanced → File Input/Output Connections → "Use file transactions for writing databases"
(It is unclear if this specific problem happens when the safe saving is on or off, so try to invert its original state and see if this helps.)
LetMeR00t
commented
4 years ago @keepassium, Well, I have to admit that using a software like yours and having developers like you that can explain in a very precise and clear manner is really great. Your solution is working (and sorry that it's wasn't linked to your issue here, I should have created another one). Toggle this settings solved the problem and just to share something with you, it could be seen on my NAS (sorry, the screenshot is in french) :
Yesterday, it was deleting then saving the file. Now it's just saving :)
Thank you again for your time.
keepassium
commented
4 years ago Thanks for confirming, @LetMeR00t . I am glad it worked out!
keepassium
commented
3 years ago iOS 14.3 release notes mention a fix for "App folders may fail to open", which seems relevant.
Does anyone still experience the issue on iOS 14.3?
keepassium
commented
3 years ago Unfortunately, iOS 14.3 still exhibits the issue.
[Thanks, Fabio]
loeffelpan
commented
3 years ago I don't know if this is really related to this issue, but I'm facing the "File does not exist" everytime I update my Database with desktop client (keepassxc). I'm using nextcloud app. Another desktop client doesn't change anything about this.
Now I am a little bit confused where the problem needs to be solved:
Any ideas?
keepassium
commented
3 years ago @loeffelpan , "File does not exist" after saving with KeePassXC is a known issue. By default, KeePassXC uses multi-stage saving which creates a new file and KeePassium cannot find the file using the old handle. The solution is to open KeePassXC settings → General → Basic Settings → File Management, and turn off the option “Safely save database files (may be incompatible with Dropbox, etc)”.
loeffelpan
commented
3 years ago I tried that option with no changes. Even after opening nextcloud app an load the kdbx-file before reopening keepassium does not fix this issue for me. Another webdav-app will propably work around it.
As I said before: I'm not sure where to locate this issue exactly. Any help on this? Debug logs or something?
loeffelpan
commented
3 years ago Maybe this matters: In recent section of my files app there are many kdbx files with same name but different timestamp. So, that file seems to be „new“ on every change. Using another client than KeePassXC doesn‘t change this behaviour. Using Boxcryptor for WebDAV-integration in iOS files works. Even with „safely save“ enabled in KeePassXC.
So, it should be a Nextcloud Problem. Never mind.
keepassium
commented
3 years ago @loeffelpan , thank you for the update. Yes, if Boxcryptor solves the problem then it was probably a Nextcloud app issue. I would check inside Nextcloud, whether it has a long queue of duplicate uploads. And maybe clear its cache, just in case.
aristippus
commented
3 years ago Similar issue for me. I use the paid version with iOS 14.4.1 with the DB on OneDrive and it worked perfectly until fairly recently. Now I can only use it in a read-only fashion (using Keepass2.x on W10 to write - even using the "extra-safe file transactions option") and even then it's somewhat hit and miss.
I get the following message when saving:
"You don't have the permission to save the file "
I can't get the error message, as the app wants me to setup Mail, which I don't use. This is a bit heavy-handed, but it starts with:
FileAccessError.swift:118 make (from:fileProvider:)
Failed to access the file[fileProvider:com.microsoft.skydrive.onedrivefileprovider,systemError:Error Domain=NSCocoaErrorDomainCode=513 "You don't have the permission to save the file "
Then there's some path stuff and the next interesting part is: NSUnderlyingError=0x281df0ed0{ErrorDomain=NSPOSIXErrorDomain Code=13 "Permission denied" ...
If you need the entire error, I can make the effort to transcribe it all
keepassium
commented
3 years ago @aristippus , thanks for the feedback. Saving to OneDrive is a different issue, courtesy of Microsoft switching OneDrive to read-only mode...
aristippus
commented
3 years ago @aristippus , thanks for the feedback. Saving to OneDrive is a different issue, courtesy of Microsoft switching OneDrive to read-only mode...
Many thanks for the very rapid response. What a ridiculous state of affairs. I'll work around it until Microsoft come to their senses.
NecatiMeral
commented
3 years ago I am having the same issue with Google Drive.
keepassium
commented
3 years ago @NecatiMeral , the issue you observed is different. It's just a random system glitch, where iOS cannot find Google Drive ("no such plugin (uuid not found)"). A reboot would fix this.
NecatiMeral
commented
3 years ago Oh Sorry, I've just encountered this issue and googled it on my mobile.
Sorry for pasting the log without formatting; the github app won't let me mark it as code / spoiler. Thanks anyway and sorry for hijacking this issue!
keepassium
commented
3 years ago @NecatiMeral, no worries. I saw you tried formatting with single quotes ', but it seems GitHub wants backticks/backquotes ` instead. You can get them on iOS by long-pressing the quote mark key. (Works with other keys, too ;)
Scrat94
commented
2 years ago I am facing the same issue wit iOS 15.1.1 and onedrive. So far it occured two times, when I added a new item in KeePassium directly. After that the connection to the file seems broken and i get something like "Onedrive is not responding". After a while suddendly i works again. I am also using KeePassiumXC. Does anybody else has an idea?
keepassium
commented
2 years ago @Scrat94 , OneDrive timeouts seem to be a rather common thing starting from September. It also becomes unresponsive in the Files app. Restarting the device usually fixes the issue and OneDrive starts working again. Given all these circumstances, I assume this is something between OneDrive and the system…
ZhangTianrong
commented
2 years ago Is there any workaround? OneDrive's connection with File app has never been satisfying and KeePassium suffers from it constantly which drove me to other KeePass implementations with their own syncing method with OneDrive. Is there a way for me to ask KeePassium to prefer a local backup than the remote file if it's modified within a certain time to at least reduced the frequency of see the error? Or are there other apps that are known to allow access to OneDrive in File through their interface instead of the Microsoft one, like what FE File Explorer does to SMB/FTP/WebDAV servers?
Edit: Tried ES File Explorer but with no luck. Ended up setting up a power automate flow to sync the OneDrive to Google Drive. There is going to be a delay and the modifications to the database will be discarded (I guess I could make it a 2 way sync but that's more complicated) but it is now usable at least.
keepassium
commented
2 years ago Is there any workaround?
There are a few reports that OneDrive and Google Drive become unresponsive after database is saved several times in a row. (So that the next version becomes due for upload while the first one is still uploading.) This seems to happen with larger files (1MB+). It is unclear if large files make storage provider run out of memory, or large files simply take longer to upload…
Does this sound relevant for your case?
Is there a way for me to ask KeePassium to prefer a local backup than the remote file if it's modified within a certain time to at least reduced the frequency of see the error?
This is largely implemented, I am ironing some final wrinkles now. If original database is unavailable, KeePassium would (optionally) load the latest local backup instead.
Tried ES File Explorer but with no luck.
Can you please describe what happened exactly? (There are quite a few diverse issues mentioned above.)
ZhangTianrong
commented
2 years ago Is there any workaround?
There are a few reports that OneDrive and Google Drive become unresponsive after database is saved several times in a row. (So that the next version becomes due for upload while the first one is still uploading.) This seems to happen with larger files (1MB+). It is unclear if large files make storage provider run out of memory, or large files simply take longer to upload…
Does this sound relevant for your case?
Yes, mine is slightly over 2 MB.
Is there a way for me to ask KeePassium to prefer a local backup than the remote file if it's modified within a certain time to at least reduced the frequency of see the error?
This is largely implemented, I am ironing some final wrinkles now. If original database is unavailable, KeePassium would (optionally) load the latest local backup instead.
This is really a good news to hear.
Tried ES File Explorer but with no luck.
Can you please describe what happened exactly? (There are quite a few diverse issues mentioned above.)
ES File Explorer is a file management app where you can log in to many online storage accounts in one place. These accounts will appear as subfolders in the drive of the app in File. So, I logged into my OneDrive account and tried to add the database there. However it keeps throwing errors when downloading that file or only downloads some 1 byte thing which I haven't been able to look at what's inside. I also noticed that I am unable to save to the file on my PC with an open KeePass XC instance whether I have safe save turned on or off. It might be digressing but this has happened a few times even when I wasn't using KeePassium. It was largely relieved when I enabled backup and safe save though. I am guessing this is the thing that will when you access the file through OneDrive mount point instead of caching from the remote through another api.
keepassium
commented
2 years ago @ZhangTianrong , thanks! 2MB is a useful data point (which also conveniently supports my hypothesis :)
Or are there other apps that are known to allow access to OneDrive in File through their interface instead of the Microsoft one, like what FE File Explorer does to SMB/FTP/WebDAV servers?
Try Boxcryptor, it used to be good. (At least before they went the "Files only" route, not sure about now.)
loeffelpan
commented
2 years ago I lately changed back to access my db via nextcloud rather than boxcryptor and can say: its working. Maybe this could be closed?
keepassium
commented
2 years ago @loeffelpan , I am happy to oblige :) Especially since iOS 15 has been around for quite a while now...
claresongs
commented
1 year ago I also encountered a similar problem on ios 16.4.1: when connecting to the nas through webdav to access the database, it always prompts 404 not found or 403 forbidden.
keepassium
commented
1 year ago @claresongs , WebDAV is unrelated to this issue. In your case, you most likely have an incorrect file URL, so the server responds that such path is either forbidden (403) or does not exist (404). Try adjusting your file URL in Safari, until it stops returning errors and shows a download prompt. Then enter that URL to KeePassium.
keepassium
commented
1 year ago @claresongs , if you have several files on different server accounts, this could be caused by #295.
For some iOS 14 users, files linked to KeePassium remain available only for a few hours. After that, any attempt to access a linked file results either in a timeout, permission denied, or "file doesn't exist" error.
To Reproduce Steps to reproduce the behavior:
Open KeePassium and observe one of the following errors:
Expected behavior The database should open normally.
User Information (please complete the following information):
Additional context
This is an extension of the common iOS 14 issue: the new system breaks KeePassium's old references to external files. That issue can be easily resolved by re-adding the files to the app. But sometimes it reoccurs.
This is reported to affect Dropbox, OneDrive, iCloud Drive, DS file, and even local storage. The typical error log is very brief:
In one case, there was a more detailed log about OneDrive. The first two messages have been translated from Dutch, the last one was is English.
Apparently, the system cannot find the OneDrive file provider extension.
Overall, this looks like an iOS 14 bug. But I will collect any relevant info here, as the issue affects more and more people.