Ok, this error will be fixed in 20.0.2:
could that be the culprit to it all?
Nopeā¦ still the dreaded āNot enough free spaceā, and no new error messages. 
Check your actual volume you are using in docker.
On the host server please run df -h /mnt/docker/volume/data/ and please copypasta the results here for the volume location you have mounted into your Docker container.
This is how df -hl looks on the docker host (i removed the tmpfs and udev stuff):
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/bmwāvg-root 28G 14G 13G 51% /
/dev/mapper/bmwāvg-home 75G 3.5G 67G 5% /home
/dev/sdb2 1.9T 209G 1.7T 12% /media/theo/Untitled 3
at the moment they are mounted into docker as such:
volumes:
- ./html:/var/www/html
- /home/nextcloud_data:/var/www/html/data
becuse the /home partition is a bit bigger. As this one is the last fresh install, I can change it to whatever you see fit.
This is my newest attempt trying to get it to work. On the original install they are docker containers on the same partition.
Here is a guide I wrote for setting up Docker on NextcloudPi. Maybe it will help (or not). Basically principles have worked fine for me.
The thing is, even if I am just doing a simple:
docker run -d -p 8080:80 nextcloud
I have the same issue. Even changing computer to one that didnāt even have docker installed before doing a fresh install of it all. No matter where I put the data, on the same disks, on different disks. No matter if I try the 19.0.4 or try the 20.0.1 I get the same results. I have them all upp and running and they all give me āNot enough free spaceā
The only common nominator left is more or less the nginx proxy server, the mac client and the browser, everything else I have changed only to get the same result.
Iād use an actual volume, which a literal directory on the server mapped to docker. This will negate the limitations. Google ādocker volumeā and move your data directory there.
I do not believe the message actually relates to the problem itself, as I have no configured nextcloud on several totally different computers, in all kind of different ways, mysql, sqlite, with tons of storages as docker containers or directly under the os disk as well as a dedicated brand new empty SSD disk.
I believe the problem might be in how (some script somewhere) tries to evaluate the disk space, or some access rights for the user/server or something.
The original docker installation worked perfectly until a week ago, now none work at all.
Did you try exactly the same on the other Docker instance you created?
Because using your local folders can cause permission issues, as the user in the docker will most likely run under a different user ID than the user in the home folder.
Please try the following situations (proceed down the list as they all work):
- New Docker, no volumes -> upload a file
- New Docker, data volume only (actual volume:
nextcloud_data:/var/www/html/data) - New Docker, these volumes:
- nextcloud_apps:/var/www/html/apps
- nextcloud_config:/var/www/html/config
- nextcloud_data:/var/www/html/data
As you can see, there is also no html folder. That one is actually not needed for the docker and just creating folders for apps and config seems to provide a more easily upgradeable docker.
If these 3 all work, then the assumption there is a permissions issue can be made. So then you can try reintroducing the data path of your own config, however i would not recommend this.
If you have a system with SELinux installed, this could also be the culprid. Disabling SELinux should then see your uploading work, but that is also not recommended.
If you need to increase the partition of your /var/lib/docker/volumes I would recommend decreasing the size of your /home partition and creating a partition that mounts to /var/lib/docker/volumes instead.
I have now removed the docker container and erased any data volumes that goes with it.
And going through M_R list:
- No volumes = āNot enough free spaceā
Well as not even the first one does work I am stopping here to await new orders :-/
df -hl on the host:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/bmwāvg-root 28G 13G 14G 47% /
/dev/mapper/bmwāvg-home 75G 3.5G 67G 5% /home
/dev/sdb2 1.9T 209G 1.7T 12% /media/theo/Untitled 3
Um, I would never erase the data volume. That is where your data isā¦ as opposed to the container itself. Your call. Iām too confused to offer further assistance; good luck.
I do understand it might sound a bit confusing but to prove the point the error message has nothing to do with any disk space I have taken a completely separate computer to test whatever any of us can come up with and so far, not even the tiniest of a a basic clean install will allow me to put any files into file folders, neither by drag and drop nor by using the upload icon.
The host machine is a Debian 10.
What is it, that no matter on what machine, a nextcloud docker installation, freshly installed or running for over a year, suddenly comes to the conclusion āNot enough free spaceā?
It must have something to do with that script and its calculations and the client, not the server.
How can I come up with exactly the same results?
- no matter the server
- no matter the installation version
- no matter the client
- no matter the OS type
- no matter the browser type
- no matter the data volume type
- no matter the disk (and partition type)
- no matter the database type
Have i missed anything to test?
This is the lab:
The original server (where the trouble started)
-
server 1
- nextcloud 19.0.4 (official docker container)
- data directory on / partition
- partitions
- 43GB free on / partition
- 207GB free on external disk
- nextcloud 19.0.4 (official docker container)
-
server 2
- nextcloud 20.0.1 freshly installed (official docker container)
- 14 GB free on / partition
- 67 GB free on /home partition
- 1.8TB free on external disk
-
Client 1
- Mac OSX 10.15.7
- Firefox 82.0 (64 bit)
- Chrome 86.0
- Safari 14.0
-
client 2
- Debian 10
- Firefox 78.4
This is what I have done so far:
On the same docker installation (19.0.4) on a Debian 9 server:
- Moved data to different disks
- Done a parallel installation on the same server but using the latest 20.0.1
- used both docker volumes and separate volumes
- changed permissions/owner on the files and directories to all combinations known to man
- Installed using MariaDB
- Installed using sqlite
On a separate Debian 10 server:
- Done a fresh install on this computer that didnāt even have docker
- used both docker volumes and separate volumes
- changed permissions on the files and directories to all combinations known to man
- Installed using MariaDB
- Installed using sqlite
client wise:
- mac & Linux on all server installations
- tried to upload a picture 78 kB
- using drag n drop gives: āNot enough free spaceā
- using the upload button gives: āNot enough free spaceā
- Create a new MD file ~80kB: works
- tried to upload a picture 78 kB
if you are running on btrfs you should inspect (not check) the involved filesystems. i ran docker a couple of times (only for testing) and was amazed that it literally created hundreds of subvols in btrfs. if your filesystem is not prepared or maintained for that special usecase, i can image you might easily run into trouble there.
maybe check with btrfs su li /DOCKER/FILES
some troubleshooting hints for btrfs can be found here
GOOD LUCK!
Thatās a valid point.
In this case however all local partitions are ext4 and there are no snapshot functionalities running. I have also tested to copy GB sized file to the disks themselves just to be sure the disk space they claim exists really do exist.
Even though the error claims āNot enough free spaceā i am certain this is not the case. It must be something else triggering it, some new API or library replying in a new format making the calculations go haywire.
I have now also installed the nextcloud docker container on a raspberry pi and still i get āNot enough free spaceā.
This limits the problem to be either the separate nginx reverse proxy that has been used on all test or on the client side. On the latter I have used several different web browsers and operating systems.
Thusā¦ it MUST be the nginx proxy, thats the only common nominator. Now what can make the proxy create situation that will end up the server thinking there is no space left?
Progress! 
The problem was in the nginx reverse proxy. There is a standard conf that somehow got activated:
One of the rows below is the culprit to this strange behavior. Once this included snippet gets disabled things work like a charm again.
YIHAA!
-------------------------------------------------------------------------
location /wp-login.php {
allow [some ip];
allow [some other ip];
allow [and another ip];
deny all;
}
location /xmlrpc.php {
deny all;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
location ~ /\. {
deny all;
}
# think this stuff below creates all trouble
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}
-------------------------------------------------------------------------
1 Like
Nice, feel free to mark solved if solved.