max upload size can't be saved

[ghost]

Steps to reproduce

1. open the settings menu
2. change the max-upload-size value to anything else as the max upload size set in the php.ini
3. save changes with button next to it
4. open the page again by navigating to it via menu and scroll to the max upload size settings

Expected behaviour

I expect that the newly set max upload size is saved properly.

Actual behaviour

Value has been reset to the max upload size set in the php.ini file

Server configuration

Operating system:
Ubuntu 16.04 LTS

Web server:
Apache/2.4.18

Database:
5.7.12-0ubuntu1.1

PHP version:
7.0.4-7ubuntu2.1

Nextcloud version: (see Nextcloud admin page)
Nextcloud 9.0.51 (stable)

Updated from an older Nextcloud/ownCloud or fresh install:
fresh install

Where did you install Nextcloud from:
https://nextcloud.com/install

http://example.com/index.php/settings/integrity/failed
No errors have been found.

List of activated apps:

Enabled:
  - activity: 2.2.1
  - admin_audit: 1.0.0
  - comments: 0.2
  - dav: 0.1.6
  - federatedfilesharing: 0.1.0
  - federation: 0.0.4
  - files: 1.4.4
  - files_pdfviewer: 0.8.1
  - files_sharing: 0.9.1
  - files_texteditor: 2.1
  - files_trashbin: 0.8.0
  - files_versions: 1.2.0
  - files_videoplayer: 0.9.8
  - firstrunwizard: 1.1
  - gallery: 14.5.0
  - notifications: 0.2.3
  - provisioning_api: 0.4.1
  - systemtags: 0.2
  - templateeditor: 0.1
  - updatenotification: 0.1.0

Are you using external storage, if yes which one: local/smb/sftp/...
no
Are you using encryption: yes/no
no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
no

Client configuration

Browser:
Firefox 47.0
Operating system:
Windows 10

Logs

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log

Content Security Policy: Die Direktive 'frame-src'  sollte nicht mehr verwendet werden. Bitte verwenden Sie stattdessen die Direktive 'child-src'. (unbekannt)
Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //# instead jquery.min.js:1:0
Content Security Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf self blockiert ("script-src http://port8000.net 'unsafe-eval'"). admin
Passwort-Felder sind auf einer unsicheren (http://) Seite vorhanden. Dies ist ein Sicherheitsrisiko, durch das Zugangsdaten gestohlen werden können.[Weitere Informationen] (unbekannt)
getPreventDefault() sollte nicht mehr verwendet werden. Verwenden Sie stattdessen defaultPrevented. jquery.min.js:5:17117

[Faldon]

Could you provide your apache config with the sensible data removed?
In my test environment, the max file upload size is saved in the .htaccess file of the installation directory.

[MorrisJobke]

In my test environment, the max file upload size is saved in the .htaccess file of the installation directory.

Please check the permission in the .htaccess file in the root directory of Nextcloud.

[Faldon]

@MorrisJobke Just checked the docs. Obviously I set permissions too lose in my test setup.
But with the permissions set according to the script in the documentation, only root may write this file, am I right?

[Faldon]

Did a fresh setup of the test environment. Set the strong permissions according to the documentation.
That leaves me with a non-writable .htacces and .user.ini in the installation directory.
Shouldn't the .user.ini be writable by the server process user? It's even as warning entry in the logs:

Can't write upload limit to /var/www/nextcloud/.user.ini. Please check the file permissions

[MorrisJobke]

Yes. Those two dot files should be writable.

[Faldon]

Then I propose changing the script provided in the documentation here:
https://docs.nextcloud.org/server/9/admin_manual/installation/installation_wizard.html#strong-perms-label
When owned by root and writable only by root, most server packages will have problems, I guess.
At least for me, I have some Ubuntu LTS (12-16), Arch and Fedora (not all for Owncloud/Nextcloud), and I don't think that in anyone of them the webserver runs as root user. Cannot speak for nginx, we only use apache at work.
@user-xy Could you provide the permissions of your .htaccess and .user.ini in your installation directory?

[ghost]

permissions from user.ini: -rw-r--r-- www www
permissions from .htaccess: -rw-r--r-- www www

this are the default rights set during installation.

[Faldon]

@user-xy Should be writable by your apache server, if www is your apache user (mine is still set to www-data on my Ubuntu boxes). In your vhost config, do you allow overriding of the .htaccess file?

[ghost]

@Faldon here is the config:
{
"system": {
"instanceid": "oc4dnxs5uoj4",
"passwordsalt": "_REMOVED SENSITIVE VALUE",
"secret": "_REMOVED SENSITIVE VALUE",
"trusted_domains": [
"port8000.net"
],
"datadirectory": "/var/www/html/nextcloud/data",
"overwrite.cli.url": "http://port8000.net/nextcloud",
"dbtype": "mysql",
"version": "9.0.51.0",
"dbname": "nextcloud",
"dbhost": "localhost",
"dbtableprefix": "oc_",
"dbuser": "_REMOVED SENSITIVE VALUE",
"dbpassword": "_REMOVED SENSITIVE VALUE",
"logtimezone": "UTC",
"installed": true,
"loglevel": 0
}
}

there are no logs written while trying to change the max value. Nor the apache error log, nor the data/owncloud.log file.

[ghost]

@Faldon, thanks a lot for your last question. All vhost entries have the AllowOverride Statement but on my new server I've just used the default config and no vhost entries. But there initialy no AllowOverride Statement exists.

Thanks for your help and you input!