Cannot delete files (pictures) using NextCloud Interface


  • Nextcloud version:
  • Operating system and version: Ubuntu 22.04.3 LTS
  • Apache or nginx version:2.4.52
  • PHP version: with Zend OPcache v8.1.2-1ubuntu2.14
  • MySQL: 8.0.35-0ubuntu0.22.04.1

The problem:

New install. No apps uploaded or added. Stock install via “” in web directory. Everything working correctly. I am an experienced server admin (since 2005 on various systems), not an expert, but not new.

I did several installs of NextCloud recently, both through Snap and Manually in order to solve what ended up being some bad PHP settings. After solving that, I blew the install away and did a new install again which went as expected and everything went smoothly.

Now… I uploaded a test picture (yes, through the web interface), just to start tinkering with NextCloud. After uploading, I could not delete it. Yes, via the NextCloud interface (NOT via the command line or SFTP).

So then I tried to delete one of the included NextCloud files to see if that was also a problem and it is.

  1. Go to “All Media”
  2. Click the stock NextCloud image (the one with the people in front of a building) and try to delete.
  3. Message: “Failed to delete Nextcloud community.jpg.:heavy_multiplication_x:

This also happens with any file, not just this one photo.

Permissions are correct in all directories and I have checked the file structure via occ.

I want to start using NextCloud, but I need to figure out why this is happening first. In searching the forums and web, I can see that this problem has popped up numerous times over the years. I am not doing anything non standard and there is no memcache in place at the moment.

I am open to exploring the stack and if any settings in PHP are causing this but to be clear, it is not working as it should.

Here are some screen shots to better explain and demonstrate. I begin by checking the photo, then try to “Delete Selection” then I get the error message.

In general, I would be very careful with manual interactions in the Nextcloud installation folder, and I would not recommend deleting any files in there.

Why do you want to delete this file in the first place? I mean, it’s not like it would take up a huge amount of space. If you don’t want these files to be copied to the user directories of new users, you can add the following to the config.php:

'skeletondirectory' => '',

Yes, the permissions are set correctly. However, (0644) rw-r--r-- www-data:www-data means that you need to be root or www-data to delete this file. But you’re probably logged in with your standard user account to your Ubuntu server, which doesn’t have permissions to write or delete anything in that directory, nor does it have permissions to delete or modify that file specifically.

It is working as designed. You’re not supposed to delete files in the Nextcloud directory directly with your normal user account.

Thank you for taking the time to respond.

However, I must have done a terrible job explaining the problem, so I have edited the issue, please take a moment and re-read if you can.

I assure you it is NOT working as designed.

I have administered servers since 2005, and while I do not consider myself an expert, I am pretty solid in my understanding of things and work with different stacks, installing, repairing and replicating those procedures in multiple settings.

I am not trying to delete files via command line or SFTP. The now deleted screen shot I originally posted was just to show that the file permissions were correct, nothing more.

The problem is that the interface is not allowing me to delete files, not files I upload, not the stock photos.

I am open to exploring my settings if you know where I might look for the cause of this issue. But the right question is NOT “why do I want to delete this file?” A user can choose to delete a stock file or a photo they uploaded for any reason. And NextCloud should honor that request. If it does not, something has gone wrong. Since NextCloud has a long history of success, the most likely cause is a setting on my system - but which one and where? I also understand 644 and www-data.

Settings dump for NextCloud for anyone willing to help trace the problem.

“system”: {
“passwordsalt”: “REMOVED SENSITIVE VALUE”,
“trusted_domains”: [
“datadirectory”: “REMOVED SENSITIVE VALUE”,
“dbtype”: “mysql”,
“version”: “”,
“overwrite.cli.url”: “”,
“htaccess.RewriteBase”: “/”,
“dbport”: “”,
“dbtableprefix”: “oc_”,
“mysql.utf8mb4”: true,
“installed”: true,
“”: true,
“mail_from_address”: “REMOVED SENSITIVE VALUE”,
“mail_smtpmode”: “smtp”,
“mail_sendmailmode”: “smtp”,
“mail_smtphost”: “REMOVED SENSITIVE VALUE”,
“mail_smtpport”: “587”,
“mail_smtpauth”: 1,
“mail_smtpname”: “REMOVED SENSITIVE VALUE”,
“mail_smtppassword”: “REMOVED SENSITIVE VALUE”,
“default_phone_region”: “US”,
“filelocking.enabled”: false,
“maintenance”: false


  • activity: 2.20.0
  • admin_audit: 1.18.0
  • bruteforcesettings: 2.8.0
  • circles: 28.0.0-dev
  • cloud_federation_api: 1.11.0
  • comments: 1.18.0
  • contactsinteraction: 1.9.0
  • dashboard: 7.8.0
  • dav: 1.29.1
  • federatedfilesharing: 1.18.0
  • federation: 1.18.0
  • files: 2.0.0
  • files_pdfviewer: 2.9.0
  • files_reminders: 1.1.0
  • files_sharing: 1.20.0
  • files_trashbin: 1.18.0
  • files_versions: 1.21.0
  • logreader: 2.13.0
  • lookup_server_connector: 1.16.0
  • nextcloud_announcements: 1.17.0
  • notifications: 2.16.0
  • oauth2: 1.16.3
  • password_policy: 1.18.0
  • photos: 2.4.0
  • privacy: 1.12.0
  • provisioning_api: 1.18.0
  • recommendations: 2.0.0
  • related_resources: 1.3.0
  • serverinfo: 1.18.0
  • settings: 1.10.0
  • sharebymail: 1.18.0
  • support: 1.11.0
  • survey_client: 1.16.0
  • suspicious_login: 6.0.0
  • systemtags: 1.18.0
  • text: 3.9.1
  • theming: 2.3.0
  • twofactor_backupcodes: 1.17.0
  • updatenotification: 1.18.0
  • user_status: 1.8.1
  • viewer: 2.2.0
  • workflowengine: 2.10.0


  • encryption: 2.16.0
  • files_external: 1.20.0
  • firstrunwizard: 2.17.0 (installed 2.17.0)
  • twofactor_totp: 10.0.0-beta.2
  • user_ldap: 1.19.0
  • weather_status: 1.8.0 (installed 1.8.0)

Maybe, or maybe I didn’t understand or read it correctly :wink: Nevertheless, it would probably have been better if you had left the original post as it was, because now we may have a better idea of what your original post was trying to tell us, but we no longer have the information it contained for reference…

Yes, I get it now, and the only things that come to mind with what you describe are either wrong permissions or SELinux / App Armor.

However, SELinux is not installed by default on Ubuntu, and App Armor isn’t known to cause problems like this, at least not in its default configuration on Ubuntu. So, if I had to guess, I’d say it’s caused by incorrect file and/or folder permissions.

The following script shows you how I set mine:


[ "$UID" -eq 0 ] || exec sudo bash "$0" "$@"

# Adjust the paths in the variables according to your setup. 

chown -R www-data:www-data $NCPATH
chown -R www-data:www-data $NCDATAPATH
find $NCPATH/ -type d -exec chmod 750 {} \;
find $NCPATH/ -type f -exec chmod 640 {} \;
find $NCDATAPATH/ -type d -exec chmod 750 {} \;
find $NCDATAPATH/ -type f -exec chmod 640 {} \;
if [ -d "$NCPATH/apps/notify_push" ]; then
sudo chmod ug+x $NCPATH/apps/notify_push/bin/x86_64/notify_push
exit 0

it would probably have been better if you had left the original post as it was, because now we may have a better idea of what your original post was trying to tell us, but we no longer have the information it contained for reference…

The post was changed because the direction of your original answer was completely wrong due to my poorly worded original post, so I took the responsibility to correct the original post to be more clear. Anything removed from that post has no impact on the question nor on solving the problem. The post as it exists now is much more clear on the problem and anyone else having this problem is more likely to come across this post and read whatever the final solution may be.

I will look at your example a bit more, but there is ZERO, ZERO justification for why NextCloud files should have to be treated differently than standard web files. The existing permissions should be more than adequate. It should not be necessary to run this kind of script on the directory once, or on a regular basis, nor should any standard Apache or PHP settings be changed to make NextCloud files different from other web files.

All directories in the web root are 755 and files are 644. User and group are all www-data and have no problem executing any files on multiple other web sites.

It is not an App Armor problem, no changes to app armor. I am the owner of the system and the only user. The full server was a recent install and I am familiar with the setup.

Further, the fact that NextCloud can upload and save a photo through the interface, but not delete it is evidence that NextCloud files have the needed permissions.

This is also not an isolated issue. There are multiple examples of people having this problem for several years. That doesn’t means it’s NextCloud’s fault, only that this is common enough, that it keeps happening and the solution should be incorporated into the install instructions - whatever that solution is.

The script doesn’t do any magic. It sets ownership and group to www-data and permissions for directories to 750 and for files to 640. I got this from here: Upgrade manually — Nextcloud latest Administration Manual latest documentation

While 755 and 644 is more than needed, it should indeed work, which indicates that there must be something else causing this issue. Unfortunately I don’t know what that might be…

Right. I understand that.

So today, I deleted the entire install and started over. Same problem. Here is how I installed:

cd /my/website/directory/root/

curl -O


rsync -avzogp /my/website/directory/root/nextcloud/*   /my/website/directory/root/

rm -R nextcloud

rm -R

chown -R www-data:www-data /my/website/directory/root/

find /my/website/directory/root/ -type d -exec chmod 750 {} \;
find /my/website/directory/root/ -type f -exec chmod 640 {} \;

sudo -u www-data php occ integrity:check-core

No issues

sudo -u www-data php occ files:scan --all

All good.

Install successful, database tables created, etc. No errors.

Log in to nextCloud, everything seems OK. Upload test file through interface, attempt to delete, same problem.

I do assume that this is a problem SOMEWHERE in my PHP config or other settings that perhaps I am not aware of, settings that work for other stacks and other apps, but not for NextCloud.

So, maybe someone can chime in and explain the process NextCloud goes through to delete a file.

For example, are there htaccess rules that are an issue? What is the PHP code doing to check for a file before deleting it, or what criteria must be met? Is a RAID 1 drive configuration a problem (can’t imagine how that could be possible, but…)?

If I try to delete by going to files and clicking on the item (photo) to delete it, I get this error:

AxiosError: Request failed with status code 403

…or in your web server / VirtualHost config…?

I don’t think that’s the right approach. But maybe you can post your web server configuration / virtual host here, or just try the “default” configuration from here: Installation on Linux — Nextcloud latest Administration Manual latest documentation, and then go from there.

The 403 Forbidden response status code indicates that the server understands the request but refuses to authorize it. Unfortunately there are a multitude of things that could cause this.

Incorrect file system permissions would be one of them, but those we can now pretty much rule out. Or as I already mentioned, it could be your Apache config / Virual Host config.

Other things that come to mind:

Reverse proxy, mod_security, some web application firewall, AppArmor, SELinux…

Do you use any of these and if so, how have you configured them?

Vhost config (relevant portions):

	<Directory "/path-to-site/web">
		AllowOverride All
		Require all granted
		Options +FollowSymLinks +MultiViews
		<IfModule mod_headers.c>
			Header always set X-Robots-Tag: "noindex, nofollow"
			Header always set Referrer-Policy: "no-referrer"
		<IfModule mod_dav.c>
			Dav off

There is no reverse proxy.

ufw status numbered
[ 1] 53/tcp                     ALLOW IN    Anywhere
[ 2] 53/udp                     ALLOW IN    Anywhere
[ 3] 80                         ALLOW IN    Anywhere
[ 4] 443                        ALLOW IN    Anywhere
[ 5] 8080                       DENY IN     Anywhere
[ 6] 53/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 7] 53/udp (v6)                ALLOW IN    Anywhere (v6)
[ 8] 80 (v6)                    ALLOW IN    Anywhere (v6)
[ 9] 443 (v6)                   ALLOW IN    Anywhere (v6)
[10] 8080 (v6)                  DENY IN     Anywhere (v6)

AppArmor is standard “out of the box” (so to speak). No changes.

mod_security is disabled, mod_ssl is enabled and restricts connections to TLS 1.2 and 1.3 and strong ciphers.

[PHP Modules]
Zend OPcache

[Zend Modules]
Zend OPcache

Is this the directory where you extracted the files from the Nextcloud zip or tarball to? If so the config looks fine I guess.

However, I have no experience with directory based installations of web applications such as Nextcloud. I only use virtual host based setups with different subdomains per site and have never had any issues like this.

So I’m not sure what’s causing this.

In my examples


Is the path specified in the Apache conf file,

<Directory "/path-to-site/web">

I simply wish to avoid disclosing the domain and provide these as examples.


Please see this thread for the issue. As I assumed it was one of my settings: htaccess rewrite rule to prevent DELETE request - options

The problem was this… For 20 years I have prevented the DELETE request via a global htaccess file for apache. This has not been a problem for other PHP sites (Wordpress), but is a problem with NextCloud.

What I have been using:

RewriteRule ^(.*)$ - [F,L]

So I have changed the condition and rule to:

RewriteRule ^(.*)$ - [F,L]

And now I can delete files and photos. But I really don’t love this.

I’m not an expert, when it comes to complex conditions and rewrite rules, but I’ll try to answer the question as best I can:

First of all, in your newly created post you don’t mention the fact that you have subdivided your sites based on Directory sections, instead of multiple VirtuaiHosts. This will almost certainly lead to missleading answers, that won’t help you.

Anyways in my humble opinion you have three options:

  1. Leave out the DELETE in the global rule, and add it to the directory section of the sites for which you want it to be active. Or add it to induviduall .htaccess files for the sites or directories where it is needed

  2. Leave everything as it is, but try to adjust the global rewrite condition to exclude Nextcloud only. No idea if this is possible in a global rule. As I said, I’m not an expert when it comes to regex and complex Apache rule constructs.

  3. Actually change all sites to separate name based VirtualHosts, and then set the rules induvidually in each VirtualHost. That would be my preferred option, and that’s how I actually host my stuff. However, this would mean that you would have to change all URLs from, e.g to, which may not be practical for you.

Example of mulltiple VirtualHosts:

<VirtualHost *:80>
    DocumentRoot "/www/site1"

    # Other directives here

<VirtualHost *:80>
    DocumentRoot "/www/site2"

    # Other directives here

I want to be appreciative of people trying to help, but I think you have been making a lot of assumptions.

I have not:

subdivided your sites based on Directory sections, instead of multiple VirtuaiHosts.

I think I can see why you might think that? Maybe?

Apache can be configured in a number of ways. For example, there is the apache2.conf file which can be made to be as basic as possible, so that you don’t make changes to it very frequently. Then you can use include files such as:

Include my-apache-settings-regarding-security.conf

Which you may change over time as new threats emerge.

You can even set up individual include files for things like WordPress specific security, or an include which manages a list of protected sub directories common to several sites (i.e.: “wp-admin” or “admin”).

Or, you can set up an include which only pertains to general htaccess rules that you want to enforce on all sites on the system.

These kinds of includes make it easy to segment different aspects of the Apache server to make managing easier or to handle performance issues.

None of that implies that I have used the apache2.conf file or any other file to list my virtual hosts, I have not. My virtual hosts are individual configuration files for each site.

I don’t generally discuss how I have segmented out my configs for any particular piece of the stack, it’s not generally needed nor wise.

What was relevant to this question from the perspective of someone trying to solve it is WHY would NextCloud allow uploads, but not Deletes?

Because I am human and make mistakes or forget to check for things, I look for solutions before asking the question. I assumed all along it was a config setting somewhere that I wasn’t considering. So, I appreciate community help to remind me of that setting.

After more searching the web yesterday, it occurred to me that NextCloud may be using the request for DELETE instead of triggering a class or section of PHP code which would perform the delete - a process that would be more secure (IMO). That is why I asked what or how NextCloud was trying to delete a file so that I could trace it from that perspective:

So, maybe someone can chime in and explain the process NextCloud goes through to delete a file.

That was the right path to the solution - NextCloud uses a DELETE request instead of actual PHP code to delete the file. Once I realized that, I remembered the specific settings I had in my htaccess settings.

First of all, I wanted to thank you for this detailed explanation, and for posting the solution. :slight_smile:

This is exactly why we need as much information as possible about your config.

Include my-apache-settings-regarding-security.conf

Yep, but if you are hosting a lot of different web apps, you probably couldn’t use the same security.conf file twice, but you would rather need a different one for each web app, like…

Include my-wordpress-security.conf
Include my-nextcloud-security.conf

…which then greatly reduces the advantage of having separate files.

Well that doesn’t change the fact that you have included this single config snippet to every site you are hosting, does it? :wink:

I mean if all the other sites are WordPress or similiar sites, that’s of course fine, but Nextcloud is a diffrenet beast.

Well, but information like this is important. And if you had mentioned it in your opening post, someone (probably not me) might have noticed it and drawn your attention to it. Without this information, it is rather unlikely that someone would come to the conclusion that you are blocking DELETE requests, because hardly anyone is using such a config for Nextcloud.

Anyways, problem solved, and we all have learnt someting. :slight_smile:

1 Like

Yes, thank you!

Yep, but if you are hosting a lot of different web apps, you probably couldn’t use the same security.conf file twice, but you would rather need a different one for each web app, like…

Include my-wordpress-security.conf
Include my-nextcloud-security.conf

I don’t feel it reduces the advantages at all. I also run a couple of Tomcat instances and that requires different settings.

It actually would be good to add the DELETE verb to my WordPress sites (already have a WP conf). And I like that the particular needs of each different stack are taken care of which requires only a few minutes of up front setup but reduces the points of concern (potentially).

Well that doesn’t change the fact that you have included this single config snippet to every site you are hosting, does it? :wink:

Meh…,. sort of. The apache.conf file contains the includes. Each virtual host file only has an additional include if needed (like with WordPress). So it’s still a global configuration which applies to 90% of the virtual hosts and then if needed, a separate include can be added to a virtual host for that situation. Since NextCloud needs this functionality I would love to find a rule that can be used just for NextCloud.


As I said, I’m not an expert, but I think you already found it here. Maybe I’m missing something, but if Nextcloud uses DELETE requests to delete files, you probably won’t be able to avoid allowing them.

I personally only block TRACK and TRACE, becauase afaik those are only needed for debuging purposes and I read it’s good practice to do so. If you want to block other request types as well, I guess you have to dig in in the inner workings of the respective apps you are serving, do some testing, and then decide on a case to case basis…

…which means there’s probably no one-fits-them-all rule if that’s your goal. However, there may be a way to exclude the Nextcloud directory in the general rule, and then set an explicit rule for Nextcloud in its directory section.

ChatGPT may be able to help with that. I have never tested it specifically in context with Apache, but I know that it generally does regex rather well. :slight_smile:

1 Like