I deleted a large folder out of external storage but for some reason the folder remains under my external storage but now owned by www-data root and can’t be deleted.
Just to clarify, the folder is no longer showing under Nextcloud.
Any ideas on how to delete this folder since any rm commands simply fail with Permission Denied?
That’s to be expected. NextCloud runs as www-data (on Fedora/RHEL type systems) and so the top level directory will be owned by it. You will need to gain privilege by:
- Using sudo (if you have privilege)
- Gaining root access (su, logging in - but not graphically)
- Finding your local friendly sysadmin.
But is it expected for the folder not to be deleted when I clicked delete via Nextcloud GUI? I think the correct behavior was for deletion to be completed and me not be writing this post.
I self host it myself and have access to the external storage server. Just can’t delete the folder even as root.
Can’t answer for the GUI, I’ll await others’ input.
You said “any rm commands”, did you mean rm(1) or rmdir(1)? the former is for files, the latter for directories.
However if you can’t delete it as root then it won’t be a simple permissions issue. Have you checked that it is empty? rmdir(1) won’t work on directories containing files, including hidden files. IF you are ABSOLUTELY CERTAIN that you want to get rid of the folder and all of its contents, there is of course rm -r, but double check before committing to this.
As root you can change the ownership [chown(1)] and permissions [chattr(1)]. If there’s an ACL you can use getfacl(1) and setfacl(1) to manipulate it, but you shouldn’t need to mess around like this unless you (or someone else) has done something odd to the root account.
The only explanation that comes to my mind is that Nextcloud, respectively the webserver user has no permission to remove the folder.
Why it doesn’t work from the command line as root or via sudo, I have no idea. You’ve already said a lot about that, and I can’t really add anything, except maybe that sudo doesn’t necessarily mean full root privileges.
However, most Linux distros by default are configured in such a way that running a command with sudo is equivalent to running it as root, so at the end of the day only the person who configured the server in question knows if any changes have been made to this default.
Good point about sudo not always meaning root. It’s also worth mentioning the (hopefully rare) instance when security have insisted that “root” is not uid=0 then set up another name for uid=0 and another UID for root. Confuses the **** out of normal sane sysadmins!