The Directory could not be moved

For me too, it’s on Windows, the webserver XAMPP is runing on my client Win10 64 bit, a virus scanner too.

But the save runs and the new version of the contents file is saved!
The error message is mostly wrong!

@mekkablue I had the same error on several MacOS X Servers. The problem I was having was due to the fact that Apache on OS X Server runs as its own user and group: “_ www” and “_ www”. That means that the default file permissions were not allowing Apache to write (or move) files - only read them.

If this is the problem, in order to fix it, you may have to change the permissions on the files.

1 Like

Thx @luxlogica that was exactly it. Now it works as expected again. For reference, what I did was move it to /Users/Shared/ (because I needed it for other users anyway), and allow Read&Write permissions for the staff group which includes www.

Hello,

I am suddenly getting “The directory could not be moved” error when removing or changing the visibility of any page on a remote server, where the site has been working before today.

I’ve tried:

  • Replacing Panel and Kirby files with fresh download
  • Clearing cache
  • Checking permissions (public_html 750, folders 755, files 644)
  • Restarting OS
  • Only having browser app open

Not sure where to go from here, any help would be brilliant.

I had this happen to me yesterday (for the first time ever), too.

For some reason, I had two of the same posts visible with following numbers and exactly the same URL-appendix. That did seem to throw Kirby off completely and it also did behave strange in other parts of the panel. You might wanna check that, maybe that happened to you too.

Yes! Thank you!

There were indeed a couple of pages with the same leading numbers, and some duplicates of projects (one visible, one invisible) which must have been confusing everything.

Thanks for your insight :smile:

It also happened to me today: I rebased changes made by users on my own Git repo with older content. A folder had been renamed (something like 6-contact to 5-contact) and for some obscure reason I ended up with both in my local content folder.

Sorry for reviving this topic, but the same error message appears for us on Kirby 2.5.4. Users can’t delete or change the status of any pages, sometimes the error also appears while trying to save changes. I’ve tried:

  • to clear the site/cache folder
  • deleting /kirby and /panel and reuploading them from the newest starterkit
  • deleting certain plugins such as Pagelock
  • checking the permissions of the folders/files (750, 755 and 644)
  • checking for duplicate folders and deleting all of them

Nothing helped. This only seems to happen on the remote server, on a local server deleting and changing the status of pages works fine. Is there anything else I can try to fix this problem, or do I have to completely uninstall Kirby and reinstall it from scratch?

This is very likely a server problem with permissions (should be 755 for folders and 644 for files) and/or (if these are correct) ownership of the files/folders.

The permissions are 755 for folders and 644 for files, so they should be correct. Incorrect ownership of files/folders would be a bit strange, since I don’t see any indication for possible problems. I’m also using the same hoster for another installation of Kirby and never had such a problem there.

Why would that be strange? The Apache user (on Ubuntu) is usually www-data, the same for the group. If your files/folders have another owner belonging to a different group, you will run into issues like not being able to save or move directories, because the user simply does not have the rights to do so.

We’re on a a shared web hosting service with no root access, which makes changing these things not that easy. Either way, all files and folders have the same and correct owner and group ownership.

Could you please check if it makes any difference if you change file and folder permissions temporarily to 777 and 666?

Also, could you post the folder structure of those incriminated pages?

And another also, if you check if


$page->isWritable()

and

$page->isDeletable()

What is the result?

  • Folder structure is content/1-blog/article-name or content/1-blog/09082017-article-name if the article is visible.

  • I inserted both these snippets into the article template

      <?php if($page->isDeletable()): ?>
      This page can be deleted.
      <?php endif ?>
    
      <?php if($page->isWritable()): ?>
      This page can be changed.
      <?php endif ?>
    

    and both sentences appeared on the site, so they should be writable and deletable.

  • I changed the folder permissions for two articles to 777 and the file permissions to 666. The error still appeared when I tried to change the status of these pages.

Well, I actually wanted to see the file tree to make sure that there are no duplicates of the type:

09082017-article-name
article-name

i.e. the same slug with date and without or any such stuff.

or different dates but same article slug.

Edit: When did this issue occur? After updating from an earlier Kirby version (which one)? Or just uploading a project you had developed locally?

2 Likes

Awesome, that fixed the problem, thank you! I did check for duplicate folders and deleted most of them, but I overlooked one folder that had the same slug (although with a different date). But does this mean that no article can have the same title, even when using a different date, otherwise the panel gets confused? That could prove a bit troublesome…

Either way, thank you for your help and patience.

Yes, exactly, slugs may not be identical. If you try to create a page via the Panel with a slug that already exists, you get an error message (“The page UID exists”). So usually, this should not happen. You can have the same title, but then you will have to change the slug manually, for example by appending a number to the slug. Any prepending folder number just indicates visibility, it is not part of the slug in the URL.

It’s not only that the Panel gets confused, you would end up with duplicate URLs which doesn’t make sense.

2 Likes