Storage Quota of "0 B" evaluates to "none" and is not persistent across logins

[BennyE]

I'm using the NextCloud primarily to distribute content to read-only users. Those users shouldn't have their own storage quota and therefore this was always set to "0 B" in previous versions. I used NC 13 for quite some time and did an upgrade to 14 and then 15(0.2.0) last Sunday and today to 15.0.4.0.

First of all thank you for your amazing work on this project, as likely you often only hear about issues via the bug tracker. I used to work in Technical Support and know how that can feel.

The issue that is caused via that is, that it may go unnoticed that users are suddenly created with "unlimited" storage quota. "0 Byte" evaluates to "none" and "unlimited" also evaluates to "none" internally. Users that have been created in the past with a storage limit of "none" (for no storage quota) are suddenly "unlimited" after the upgrade. I caught that issue on time and manually went through my 1800+ users to fix is manually for those that were not set to "use system default storage quota". A workaround for the "0 B" evaluating to "none" is to set this to "1 B"(yte), as this value is being saved properly and new users could only store 1 Byte (which will hopefully not do so much harm).

I understand that my use case might be different from others.

Steps to reproduce

1. Go to "Admin -> Users"
2. Open the settings on the lower left-hand side and look at the storage quota
3. 
4. Try to set this to "0 B" (for 0 Byte) and you'll notice that it changes to "none", but will not be a persistent setting across logins

Expected behaviour

I'd expect "0 B" to evaluate to "0 B" and not "none" and have this setting persistent across logins (and also as default for users other than the Admin user that have the entitlement to create new users)

Actual behaviour

Setting of "0 B" evalutates to "none" and will reset to "Unlimited"/"Unrestricted" on next access (logout/login) to Admin -> Users

Server configuration

Operating system: Debian 9.7 (stretch)

Web server: Apache 2.4.25-3+deb9u6

Database: MariaDB 10.1.26-0+deb9u1

PHP version: php 7.0.33-0+deb9u1

Nextcloud version: 15.0.4.0

Updated from an older Nextcloud/ownCloud or fresh install: 13 (manual update) -> 14 (manual update) -> 15.0.2.0 (occ CLI updater) -> 15.0.4.0

Where did you install Nextcloud from: ZIP-file (so no Debian package is involved for NextCloud itself)

Signing status:

Signing status

No errors have been found.

List of activated apps:

App list

# sudo -u www-data php occ app:list
Enabled:
  - accessibility: 1.1.0
  - activity: 2.8.2
  - admin_audit: 1.5.0
  - cloud_federation_api: 0.1.0
  - comments: 1.5.0
  - dav: 1.8.1
  - federatedfilesharing: 1.5.0
  - federation: 1.5.0
  - files: 1.10.0
  - files_pdfviewer: 1.4.0
  - files_sharing: 1.7.0
  - files_texteditor: 2.7.0
  - files_trashbin: 1.5.0
  - files_versions: 1.8.0
  - files_videoplayer: 1.4.0
  - firstrunwizard: 2.4.0
  - gallery: 18.2.0
  - groupfolders: 2.0.2
  - logreader: 2.0.0
  - lookup_server_connector: 1.3.0
  - nextcloud_announcements: 1.4.0
  - notifications: 2.3.0
  - oauth2: 1.3.0
  - password_policy: 1.5.0
  - previewgenerator: 2.0.0
  - provisioning_api: 1.5.0
  - serverinfo: 1.5.0
  - sharebymail: 1.5.0
  - support: 1.0.0
  - survey_client: 1.3.0
  - systemtags: 1.5.0
  - theming: 1.6.0
  - twofactor_backupcodes: 1.4.1
  - updatenotification: 1.5.0
  - workflowengine: 1.5.0
Disabled:
  - encryption
  - files_external
  - user_ldap

Nextcloud configuration:

Config report

# sudo -u www-data php occ config:list system
{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "owncloud.alu4u.com",
            "192.168.70.20"
        ],
        "overwritehost": "owncloud.alu4u.com",
        "overwriteprotocol": "https",
        "overwrite.cli.url": "https:\/\/owncloud.alu4u.com",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "dbtype": "mysql",
        "version": "15.0.4.0",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "default_language": "de",
        "logtimezone": "UTC",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "8025",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "loglevel": 3,
        "appstore.experimental.enabled": true,
        "maintenance": false,
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

Are you using external storage, if yes which one: local

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: Firefox 65.0; Chrome 72.0.3626.96 (Official Build) (64-bit)

Operating system: macOS 10.13.6

[EvilBMP]

I can confirm this issue!

Workaround:

If you are able to use the command line, then you can set the default quota via CLI.
php occ config:app:set files default_quota --value="0 B"