Access Denied error at admin/customers.php

[fakeDecoy]

I'm getting an "Access Denied" error in my browser when I try to access this admin URL this morning. I only noticed the error this morning, but it might have been a few days since I tried accessing that page.

http://www.mystore.com/admin/customers.php

The orders page and everything else in the admin and catalog I seem to be able to access just fine.

I checked the error logs in the cache folder and there's nothing there except the usual PHP warnings about the strstr() function that I've been getting for years.

I can't think of any files I have updated recently except for these, which I don't think have anything to do with that page.

templates/mytemplate/common/tpl_header.php
includes/languages/mytemplate/html_includes/define_main_page.php

What could be causing this?

[kobra]

Check the permissions for that file against other files that exist there

[fakeDecoy]

So the permissions for the customers.php file seems to get changed every Sunday to cause this error. I have to go into filezilla every week and fix it back. My webhost says they aren't doing it. No other file's permissions on my server seems to be changed. They're saying it must be a script I have running. I can't imagine what script would be causing it. The only cron jobs I run are database backups and some feed exports by Magneticone.

[carlwhat]

check the timestamp of the cron jobs v. the timestamp of the customers.php when it gets changed on sunday... if it is happening every sunday at the same time, it does seem like the culprit could be a cron job.

[fakeDecoy]

check the timestamp of the cron jobs v. the timestamp of the customers.php when it gets changed on sunday... if it is happening every sunday at the same time, it does seem like the culprit could be a cron job.

A permissions change doesn't change the timestamp. It's still last modified in 2011.

[carlwhat]

i'm making an assumption that your host is running linux due to your comment on cron jobs. assuming that is the case, and that your host allows ssh access, you should ssh to the server and try:

ls -lc

which should tell you the when any substantive change to the inode occurred and that does include a permission change. although it is not limited to a permissions change.

i am not sure if you are able to check this with fileZilla; you will probably need to ssh to the server. you can then better check the timing of your cron jobs as well with:

crontab -l

good luck!