I've uploaded files for my website from my home test server to my hosting account on awardspace.
It is weird that some pictures work when directlinking but others don't and I don't get why
It are jpg files, and it's in a particular folder /images
and even weirder is that with some jpg files in that folder direct linking works, but with other jpgs it doesn't. I get an 403 error, while the file is there. I can see it with filezilla....
So what is wrong? on the home test server direct linking works.
EDIT: I'm guessing it has something to do with their forbidden words list. Although it's odd as pictures do not contain text?! I certainly hope they don't enforce the list on a paid hosting account as I already ordered one...
I have been using Awardspace very recently, and used core-ftp lite ftp program to easily change permissions to read, write and execute. It all works fine with me.
Related
Yesterday everything was working just fine but now today when I try to access a PDF or RTF file served by IIS, I get a 404 error (when accessing it through HTTPS) or a 403 error (when accessing it through HTTP). I can still access DOC files hosted by this server. What could have possibly changed to prevent the PDF and RTF files from loading? They are being generated properly in a folder that belongs to a virtual directory being requested.
Looks like I had two similarly named folders and the files were being written to one folder and read from the other, which of course did not contain them because they were actually in the first folder. Fixing this issue solved my problem. Must have goofed up a configuration setting somewhere that this broke...
I'm trying to use the Joomla ARS. I've set it up and it seems to work for everything except the download of zip files.
I've set it up so that you can see the file in the front end but when you click on it a:
The requested document was not found on this server
error is thrown.
I've tried directly linking the file and it downloads fine. I've also set up an article to check that it'll download and again it works fine. So I don't think there are any permission issues since the zip file can be downloaded just not by using ARS.
Finally I've also tried different file types in ARS and if I swap the zip file for an xml file or a pdf file they both download fine.
Any ideas about how to debug?
I figured it out :)
The site had add a suffix to url switched on which was stopping it getting the correct route. Changed that and it worked as expected.
Working on this website I was going to add a simple .hide(); and onclick animate(); functions to a menu, but the menu div wasn't closed (stupid mistake). When I upload the file to the live website it hides everything in the website cause of the open div tag, obviously I fix it and also delete the jQuery function but when I upload the file to the FTP the website is still showing the old file for some reason.
More info: I already deleted the cache/cookies/history off this computer and reloaded the page and re uploaded the file. Also tried in 4 different computers with 3 different IPs I did a search of all the files and the code is not there anymore. Deleted the directory and it still shows up.
As i can suggest from your question, i can say its a stupid mistake. Happened to me a few times.
I would try the following:
Make a working folder of your "new" website - locally
Delete EVERY file and folder from your server (of course only your whole website)
Get sure that nothing is displayed when you open it at the browser, should be fail
Now load your local folder completely to the new, empty space at your FTP
Rather than re uploading the file. Delete it, visit it in your browser and verify you get a 404 and then upload it again.
I have had this problem before when re-uploading a file in some FTP clients.
Just getting my head around the new Azure web sites feature and hitting my first obstacle. I'm deploying a PHP site which writes cache data to the file system, but the app is throwing an error because the folder it wants to write to does not have write permission. Is it possible to set permissions on folders or is this a no-no?
I can probably work round this but would like to know if it's possible.
Folder permissions cannot be set/customized. This means whatever location your app writes to should be under your site root.
Your site can only write to locations under C:\DWASFiles\Sites\[siteName]\VirtualDirectory0 and to the %TEMP% folder.
Two caveats here:
Stuff can't be written directly under VirtualDirectory0, you have to create a subfolder under there and place your files in that subfolder
The %TEMP% folder really is temporary! If your site instance goes down for any reason and is brought back up somewhere else then everything in your %TEMP% folder will be gone. Use it only for files that really are temporary.
Is the folder that the app is trying to write to under the site's folder?
It's my understanding that folder permissions cannot be set/changed. But I haven't seen anything from Microsoft that definitively says "yes" or "no" to that.
It should be possible using webdeploy.
However I don't think there is a way do it without manually setting up the webdeploy package - as described in the post http://blogs.msdn.com/b/azureappgallery/archive/2013/04/03/set-file-folder-permissions-for-your-content-on-azure-website-using-web-deployable-package.aspx.
I'm using multiple computers for development and I want to be able to store my files in my dropbox folder. I went to change the physical path in IIS from c:\inetpup\wwwroot to the dropbox folder but I get this error:
The requested page cannot be accessed
because the related configuration data
for the page is invalid.
I couldn't find the config file so I was wondering if anyone had done this before or whether there a better way to sync everything nicely across several PCs?
I tried it (IIS 7.5, Win 7) and it should work just fine to let your physical path of your web look at your dropfox folder. I would guess your web.config file generally contains malformed XML (see KB942055).
I'd suggest, try to map it to an empty folder just with an index.html file and see if this error still occurs.
As a workaround, I guess you can put Dropbox in your wwwroot folder and set up a virtual directory that points to Dropbox. However, there are some security issues that may hinder you from doing so. I come across a nice tutorial on how to set up Dropbox to IIS as FTP Publishing. Hope it helps.
Hodgin's guide on using Dropbox as FTP publishing.