Wget ошибка 403 forbidden

Are you stuck with Wget 403 forbidden? Here’s how we fix it.

Usually, wget 403 forbidden occurs due to errors with cookies, referer, user agent and so on.

At Bobcares, we often receive requests to fix this error as part of our Server Management Services.

Today, let’s discuss how our Support Engineers fix this error easily for our customers.

Why does Wget 403 forbidden error occur?

As we all know, we use the wget command to download files from the server.

But, it often shows up 403 Forbidden error. Let’s discuss some major reasons that cause this error.

Cookies, data that a server sends to the user’s web browser can cause this error. Error with these cookies will reject the request and cause 403 forbidden.

And, not setting the Referer header properly will also result in a forbidden error.

User-agent is a string that introduces the browser and operating system to a server. Different requests yield different responses depending on the user agent. It can also cause the forbidden error in wget.

How we solve the forbidden error?

Recently, one of our customers approached us with a wget error. He tried to download a file using wget and ended up getting a 403 forbidden error.

Our Support Engineers checked the error in detail. On checking, we found that the server was checking the referer.

On adding it to the command line, he was able to download the file using wget.

Similarly, some HTTP requests will get bad responses as they reject user agents that do not start with Mozilla or contain Wget.

So, to resolve the error, we can set a custom user agent as follows.

This will resolve the error easily.

[Need more assistance to fix this error?- We’re available 24/7]

Conclusion

In short, wget 403 forbidden occurs due to errors with cookies, referer, user agent and so on. In today’s writeup, we discussed how our Support Engineers fix this error for our customers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

I try to download a file with wget and curl and it is rejected with a 403 error (forbidden).

I can view the file using the web browser on the same machine.

I try again with my browser’s user agent, obtained by http://www.whatsmyuseragent.com. I do this:

wget -U 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' http://...

and

curl -A 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' http://...

but it is still forbidden. What other reasons might there be for the 403, and what ways can I alter the wget and curl commands to overcome them?

(this is not about being able to get the file — I know I can just save it from my browser; it’s about understanding why the command-line tools work differently)

update

Thanks to all the excellent answers given to this question. The specific problem I had encountered was that the server was checking the referrer. By adding this to the command-line I could get the file using curl and wget.

The server that checked the referrer bounced through a 302 to another location that performed no checks at all, so a curl or wget of that site worked cleanly.

If anyone is interested, this came about because I was reading this page to learn about embedded CSS and was trying to look at the site’s css for an example. The actual URL I was getting trouble with was this and the curl I ended up with is

curl -L -H 'Referer: http://css-tricks.com/forums/topic/font-face-in-base64-is-cross-browser-compatible/' http://cloud.typography.com/610186/691184/css/fonts.css

and the wget is

 wget --referer='http://css-tricks.com/forums/topic/font-face-in-base64-is-cross-browser-compatible/' http://cloud.typography.com/610186/691184/css/fonts.css

Very interesting.

linux

--user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0"

You have two unrelated problems.

«403 Forbidden» is a web server error. You have to fix your URL.

When you ran wget https://releases.mattermost.com/X.X.X/mattermost-X.X.X-linux-amd64.tar.gz, you got a 403: Forbidden error. This is an error from the web server and is unrelated to the user account used to download the file.

When you attempt to load a page or download a file and you specify an incorrect URL, a 404: Not Found errors is the most common result. But a 403 error can occur sometimes in this situation, and that appears to be what is happening here. It looks, from both the command you ran and wget‘s output, like you forgot to put the actual version numbers in the URL.

On my system, I am able to get exactly the same error using the URL with X.X.X instead of an actual version number:

ek@Io:~/Downloads$ wget https://releases.mattermost.com/X.X.X/mattermost-X.X.X-linux-amd64.tar.gz
--2017-01-17 03:15:30--  https://releases.mattermost.com/X.X.X/mattermost-X.X.X-linux-amd64.tar.gz
Resolving releases.mattermost.com (releases.mattermost.com)... 54.192.147.30, 54.192.147.18, 54.192.147.46, ...
Connecting to releases.mattermost.com (releases.mattermost.com)|54.192.147.30|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2017-01-17 03:15:32 ERROR 403: Forbidden.

And if I use the correct URL, it works:

ek@Io:~/Downloads$ wget https://releases.mattermost.com/3.6.0/mattermost-team-3.6.0-linux-amd64.tar.gz
--2017-01-17 03:09:50--  https://releases.mattermost.com/3.6.0/mattermost-team-3.6.0-linux-amd64.tar.gz
Resolving releases.mattermost.com (releases.mattermost.com)... 54.192.147.156, 54.192.147.30, 54.192.147.160, ...
Connecting to releases.mattermost.com (releases.mattermost.com)|54.192.147.156|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 27221349 (26M) [application/x-gzip]
Saving to: ‘mattermost-team-3.6.0-linux-amd64.tar.gz’

mattermost-team-3.6.0-linux- 100%[==============================================>]  25.96M   106KB/s    in 2m 6s

2017-01-17 03:11:58 (212 KB/s) - ‘mattermost-team-3.6.0-linux-amd64.tar.gz’ saved [27221349/27221349]

(Both the working and non-working URLs are from your post. I don’t actually know exactly what file you need.)

The mattermost user isn’t a sudoer.

Not all users may run programs as root (or at all) with the sudo command. The file /etc/sudoers, or a file in /etc/sudoers.d, must be configured to allow them to do so. Most commonly, this is achieved by putting the user in a group that one of those files permits to run commands.

In particular, to make a user an administrator on an Ubuntu system so that they are permitted to run any command as root using sudo, add the user to the sudo group:

sudo usermod -aG sudo mattermost

Of course, you must run that as a user who can run commands as root with sudo already. (You were able to run sudo passwd mattermost, so I know you have at least one such user.)

Keep in mind:

• You must only do this if you really want that user to have full power to do anything. They will have the same power as you. Once you’ve decided you want that, though, you should go ahead and simply add the user to the sudoers group. There is usually no need to actually edit any configuration files for sudo — they’re already set up to recognize the sudo group as conferring administrative power.
• If for some reason you instead choose to edit /etc/sudoers or create/edit a file in /etc/sudoers.d, it is important that you use the visudo utility to do it, because it performs a syntax check to make sure your changes will be understood by sudo. If sudo sees incorrect syntax in a sudoers file, then it will completely refuse to work. For servers you only have remote access to, this can lock you out of the system.

Finally, it’s very rare that you actually have to manually download a file with wget as root. In this case, you didn’t — the error was an incorrect URL and the «forbidden» message was from the web server. Therefore:

• If this is the only reason mattermost needed to use sudo, you probably shouldn’t give that user account these abilities, because there’s no need.
• Even if mattermost really does need to be an administrator, they should perform actions as themselves (without sudo) rather than as root (with sudo) except when there is a clear reason to do the latter.