I keep getting the following error logged in watchdog:

The directory public://xmlsitemap does not exist or is not writable

I have checked this and the xmlsitemap folder does exist in the public files, and is writable.

To clarify, it is writable by owner and group (www-data). Does it need to be writable to anyone? I checked the dates on the folders, and the files/xmlsitemap folder was created a couple of years ago, and inside that is a folder with a hash name which was created today. Both folders are writable by apache. Inside the hash named folder is an xml file, also created today.

So as far as I can tell everything looks fine. XMLSitemap appears to be working fine too, it's just filling up my logs with apparently false warnings.

Comments

dpovshed’s picture

dpovshed CreditAttribution: dpovshed commented
Category: Bug report » Support request

@scott.whittaker, is the case reproducible with the latest version of module (2.2) ?

ron_s’s picture

ron_s CreditAttribution: ron_s commented
Version: 7.x-2.0 » 7.x-2.2

We are running 2.2, and have seen this error when the Base URL doesn't match the current URL of the site. This can come up as an issue if the Base URL value was not updated after migrating a site from a development to live server.

Is it possible to add a Status Report message that informs administrators when the Base URL variable doesn't match the site URL?

dpovshed’s picture

dpovshed CreditAttribution: dpovshed commented

@ron_s, thank you for testing and your feedback!

If this check help to detect the problem - I'll gladly implement it. Should be easy to add and useful to have.

ron_s’s picture

ron_s CreditAttribution: ron_s commented

General question: is there a use case where it is worthwhile to have the XML Sitemap Base URL set as a different value than $base_url? I've always set the values the same.

Here's a better solution if it's necessary to allow for sitemaps with different base URLs:

  1. Add a checkbox to the Default Base URL section in Advanced Settings (/admin/config/search/xmlsitemap/settings). The checkbox should be titled, "Set XML Sitemap Base URL to be different than the Base URL of this site."
  2. By default, the checkbox is not selected. When not selected, the "Default Base URL" field is hidden.
  3. If the checkbox is selected, the "Default Base URL" field is shown and the user can enter an XML Sitemap Base URL as an override.
  4. If the checkbox is not selected, the XML Sitemap module uses $base_url if it's set, or the site domain if $base_url is not set.

If there's not really a compelling use case for the field, maybe it should be removed entirely and just use $base_url and the site domain?

dallen1’s picture

dallen1 CreditAttribution: dallen1 commented

Hi, is there anything that can be checked other than verifying the hostname?

Our watchdog log is filling up with the following 2 messages every five minutes for us.

The directory public://xmlsitemap does not exist or is not writable.
The file permissions could not be set on public://xmlsitemap

Like scott.whittaker said, everything is writable and the file is generated correctly.

I've verified the hostname is correct and have checked "Disable cron generation of sitemap files." (I'm using drush instead)

We're using version 7.x-2.2 on 7.36.

dallen1’s picture

dallen1 CreditAttribution: dallen1 commented

Well, the error is gone if I change the file permissions. My log stops filling up if I set the folders to 777 from 775 and the xml file to 666 from 664. My owner and group are both www-data. This seems peculiar that the module, or watchdog, is testing the writability and permissions of the directory from a user other than www-data.

dpovshed’s picture

dpovshed CreditAttribution: dpovshed commented

I normally recommend for those who likes to work with drush either:

1) run drush as a webserver user (www-data in your case);
2) alternatively you may keep 775/664 permission but execute something like sudo chown -R www-data:dallen files . This should grant access not only to webserver but also to you to all files.

Hope this helps!

frederickjh’s picture

frederickjh
he/him
Primary language English
Location The Big Island of Hawai'i
CreditAttribution: frederickjh commented

Hi!

I just came across this error and another similar error message that has a patch. The patch(#2568123: "Unable to create directory" when used in installation profile.) added the permission to change the file/folder permissions by adding FILE_MODIFY_PERMISSIONS. I have to wonder if something similar is needed here to fix this issue.

God Bless!
Frederick