25.0.3 (as indicated by output from `occ –version` above).
25.0.3 (as indicated by output from `occ –version` above).
25.0.3 (as indicated by output from `occ –version` above).
The exit code issue is still there:
# sudo -u www-data /usr/bin/php /var/www/nextcloud/occ --version
Nextcloud 25.0.3
# sudo -u www-data /usr/bin/php /var/www/nextcloud/occ files:scan -- nonexistantuser
Unknown user 1 nonexistantuser
+---------+-------+--------------+
| Folders | Files | Elapsed time |
+---------+-------+--------------+
| 0 | 0 | 00:00:00 |
+---------+-------+--------------+
# echo $?
0
Still present in Nextcloud 3.21.2. My device is a Samsung A9 running Android 10.
Hi @claucambra, I tested the appimage and the issue still reproduces.
Using a path with umlauts as logDir
causes an incorrectly encoded directory to be created and used as log directory, instead of the specified directory.
nextcloud.cfg
. Set logDir=/home/jani/Tänne
(applying appropriately to your home directory)ls /home/jani/Tänne
A listing of new log files residing in /home/jani/Tänne
.
This question is unclear. The log files are the ones affected.
Linux
Ubuntu 20.04
Distro package manager
24.0.4
3.5.4-20220806.084713.fea986309-1.0~focal1
Updated from a minor version (ex. 3.4.2 to 3.4.4)
Encryption is Disabled
No response
This bizarre and otherwise exhaustingly long issue form is lacking a ”What happens instead of my expected outcome” question, so I’m entering it here instead: there are no logs in the specified target directory (it doesn’t even exist if you’ve not created it beforehand). Instead, like in the ye olden days, there is now a directory called Tänne
containing the logs. In nextcloud.cfg
the path has been re-encoded as logDir=/home/jani/T\xc3\xa4nne/
which is apparently how it should be, since a similarly re-encoded value for a ...localPath
with umlauts in the [accounts]
section has been working just fine for as long as I can remember using it.
Sorry for necromancing, but because Google seems to like this thread, I just thought I’d add a mention that a check_data_directory_permissions
option for config.php
has since been implemented (and backported down to NC12), and it allows the admin to turn off the automatic permissions reset (by assigning it false).
This is discouraged however, and ACLs or other means of managing access are still the better option where available.
Looks like it waits a fixed 30 minutes before letting you run it again. You can either wait it out (as you probably have by now) or, if you’re impatient (like me) and really sure it’s not running already, `SELECT * FROM ’oc_appconfig’ WHERE ’configkey’ LIKE ’lastActivity’` and delete that timestamp.
You can edit out your password salt and secret.
Just to clarify, in case someone else is about to make the stupid mistake I almost made: I’m pretty sure @JasonBayton meant @vCentre should edit their message (above) which contains the salt and secret, not that they should edit those out of their live config.php on the server, as that would cause the loss of all existing passwords.
So I did some more digging and turns out this was all due to my having botched the migration. I had used the experimental upgrader script, which kept failing due to timeouts, so I went ahead and tried to finish it up manually. With everything else apart from the Android app working as expected, I was fooled into thinking I had nailed it. But with this issue persisting, I just had to check, and wouldn’t you know, there were still all these files lingering from the previous Owncloud installation that I hadn’t replaced.
Tl;dr; re-downloaded 9.0.52, replaced the existing installation with the files extracted from the download, and the Android app now also connects without issue.
@HucSte, I’m not sure your issue is related, but if you also migrated from Owncloud, you could try re-installing Nextcloud files afresh.
No worries, thanks for taking a look at this @tobiasKaminsky!