android
android copied to clipboard
Default storage directory not writable in some Xiaomi devices
⚠️ Before posting ⚠️
- [X] This is a bug, not a question or an enhancement.
- [X] I've searched for similar issues and didn't find a duplicate.
- [X] I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
- [X] I agree to follow Nextcloud's Code of Conduct.
Steps to reproduce
- Open Nextcloud Android app
- Login to Nextcloud server (User Account is in initial state after creation on new installed server)
- Rename standard folder "Photos" to "Photos & Videos"
Edit: Renaming of any directory via App has the same result
The Folder contains the three initial pictures only. No data has been uploaded to the user account (nor the server).
Expected behaviour
Either folder will be renamed or an error is displayed, if naming conventions are not met.
Actual behaviour
App crashes with error message seen in "android logs"
Android version
12 SKQ1.211006.001
Device brand and model
Xiaomi
Stock or custom OS?
Stock
Nextcloud android app version
30200390
Nextcloud server version
24.0.1
Using a reverse proxy?
I don't know
Android logs
Cause of error
Exception in thread "main" java.lang.NullPointerException: Attempt to invoke virtual method 'boolean com.owncloud.android.lib.common.operations.RemoteOperationResult.isSuccess()' on a null object reference
at com.owncloud.android.ui.activity.FileActivity.onRemoteOperationFinish(FileActivity.java:348)
at com.owncloud.android.ui.activity.FileDisplayActivity.onRemoteOperationFinish(FileDisplayActivity.java:1649)
at com.owncloud.android.services.OperationsService.lambda$dispatchResultToOperationListeners$0(OperationsService.java:778)
at com.owncloud.android.services.OperationsService$$ExternalSyntheticLambda0.run(Unknown Source:6)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:210)
at android.os.Looper.loop(Looper.java:299)
at android.app.ActivityThread.main(ActivityThread.java:8118)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:556)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1045)
App information
- ID:
com.nextcloud.client - Version:
30200390 - Build flavor:
gplay
Device information
- Brand:
Xiaomi - Device:
vili - Model:
2107113SG - Id:
SKQ1.211006.001 - Product:
vili_eea
Firmware
- SDK:
31 - Release:
12 - Incremental:
V13.0.5.0.SKDEUVF
Server error logs
No response
Additional information
Server is running as managed webhosting and has just been setup. The user account has no admin rights and has only the preset of initial folders.
@thethan666 The report states that a fresh login is required to reproduce it. Can you tell when this issue stops happening?
@thethan666 The report states that a fresh login is required to reproduce it. Can you tell when this issue stops happening?
@ezaquarii Sorry for the misleading information. I was trying to mention, that the server is in its initial state after a fresh installation. Nothing was done on the nextcloud instance beside the setup of the hosting provider. It has been updated to be more precise.
I setup the Nextcloud app, logged in to my server instance and directly tried to rename a directory.
On another try, the issue consist on EVERY renaming attempt of EVERY directory. It has nothing to to with certain characters like "&" or whitespace in the name. If the directory is renamed via webinterface, the new folder name is displayed in the app without any issues.
@thethan666 Thank you for the clarification.
Once you restart the application after the crash and refresh the folder view, can you tell if the renaming succeeded on the server side?
Hey @thethan666, can you get logs from the app? Instructions here: https://github.com/nextcloud/android#getting-debug-info-via-logcat-mag Feel free to search and replace the output for your username and server name, for privacy reasons.
Developer reference: http://github.com/nextcloud/android/blob/master/app/src/main/java/com/owncloud/android/operations/RenameFileOperation.java#L111-L111
The exception is just logged and a null result is returned.
@AlvaroBrey, here you go.
I have created a new user account and deleted all other account from the app to have a clean log.
logcatOutput_withErrors_Xiaomi.txt
Despite that, I logged in as the same user on another device and renamed the same folder successfully. Same Nextcloud Server, same Nextcloud App Version, different Android version (Android 10 - Huawei EMUI 10.0.0).
Actual error trace:
08-03 15:04:43.866 32397 32447 E RenameFileOperation: Unable to create parent folder /storage/0000-0000/Android/media/com.nextcloud.client/nextcloud/tmp
08-03 15:04:43.866 32397 32447 E RenameFileOperation: Rename /FolderName/ to NewFolderName:
08-03 15:04:43.866 32397 32447 E RenameFileOperation: java.io.IOException: Unexpected error: temporal directory could not be created
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at com.owncloud.android.operations.RenameFileOperation.isValidNewName(RenameFileOperation.java:182)
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at com.owncloud.android.operations.RenameFileOperation.run(RenameFileOperation.java:79)
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:187)
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at com.owncloud.android.services.OperationsService$ServiceHandler.nextOperation(OperationsService.java:440)
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at com.owncloud.android.services.OperationsService$ServiceHandler.handleMessage(OperationsService.java:405)
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at android.os.Handler.dispatchMessage(Handler.java:106)
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at android.os.Looper.loopOnce(Looper.java:210)
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at android.os.Looper.loop(Looper.java:299)
08-03 15:04:43.866 32397 32447 E RenameFileOperation: at android.os.HandlerThread.run(HandlerThread.java:67)
Which points to this line: https://github.com/nextcloud/android/blob/0ba4effd83f293f0aaa378aeeef8bdc5bf13f4e3/app/src/main/java/com/owncloud/android/operations/RenameFileOperation.java#L182-L182
It would look like, in this particular phone, there's already a file at /storage/0000-0000/Android/media/com.nextcloud.client/nextcloud/tmp, which I don't understand. Uninstalling and reinstalling the app should fix this, but I don't know how that file could have gotten there in the first place.
After uninstalling and reinstalling the app, the issue persists:
08-04 13:19:36.594 27485 27549 E RenameFileOperation: Unable to create parent folder /storage/0000-0000/Android/media/com.nextcloud.client/nextcloud/tmp
08-04 13:19:36.594 27485 27549 E RenameFileOperation: Rename /NewFolderName/ to FolderName:
08-04 13:19:36.594 27485 27549 E RenameFileOperation: java.io.IOException: Unexpected error: temporal directory could not be created
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at com.owncloud.android.operations.RenameFileOperation.isValidNewName(RenameFileOperation.java:182)
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at com.owncloud.android.operations.RenameFileOperation.run(RenameFileOperation.java:79)
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:187)
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at com.owncloud.android.services.OperationsService$ServiceHandler.nextOperation(OperationsService.java:440)
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at com.owncloud.android.services.OperationsService$ServiceHandler.handleMessage(OperationsService.java:405)
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at android.os.Handler.dispatchMessage(Handler.java:106)
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at android.os.Looper.loopOnce(Looper.java:210)
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at android.os.Looper.loop(Looper.java:299)
08-04 13:19:36.594 27485 27549 E RenameFileOperation: at android.os.HandlerThread.run(HandlerThread.java:67)
At least at /storage/emulated/0/Android/media/ there is no folder com.nextcloud.client at all.
Is the emulated file system diverging from the actual one at this directory? Or is the app lacking the rights to write to specific paths on the local file system? (In android settings, the app is allowed to manage all Data)
Can you check which folder you have set as storage in the app's settings?
Or is the app lacking the rights to write to specific paths on the local file system? (In android settings, the app is allowed to manage all Data)
Barring vendor-specific stuff (it's a Xiaomi after all), there should be no problem for this even without permissions. Android/media/com.nextcloud.client should be an app-private directory with full access
All right... the standard app setting is /storage/0000-0000/Android/media/com.nextcloud.client, which apparently is not allowed to be used by the app on my device.
- Go to "Settings"
- "Speicherordner" (select the app path)
-> NO option is selected here! Options are:
storage/emulated/0/Android/media[...],data/user/0[...]andstorage/emulated/0/Android/data[...] - Select first option
storage/emulated/0/Android/media/com.nextcloud.client - Rename a folder -> works absolutely fine
Unfortunately Xiaomi seems to block anything and anybody to work on the actual directories. Only working with the emulated directory is allowed. The Nextcloud app seems not to check, if the standard path is available. At least while manually selecting a local path for the app, the correct values are queried from the android system.
Unfortunately Xiaomi seems to block anything and anybody to work on the actual directories. Only working with the emulated directory is allowed. The Nextcloud app seems not to check, if the standard path is available. At least while manually selecting a local path for the app, the correct values are queried from the android system.
Wow, many thanks for your findings! I'll be renaming the issue to reflect this. In the meantime I hope that this workaround is sufficient for you