# Crypt\_r() issue when viewing HTTP auth page

**URL:** <https://www.ruby-forum.com/t/crypt-r-issue-when-viewing-http-auth-page/225200>\
**Category:** NGINX\
**Created:** [December 20, 2012, 1:43am UTC](https://www.ruby-forum.com/t/crypt-r-issue-when-viewing-http-auth-page/225200 "2012-12-20T01:43:42Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\
**Post date:** [December 20, 2012, 1:43am UTC](https://www.ruby-forum.com/t/crypt-r-issue-when-viewing-http-auth-page/225200/1 "2012-12-20T01:43:42Z")

</div>

When viewing a page that is HTTP auth password protected, we sometimes  
get  
an error 500 (internal server error), but 100% of the time, a browser  
reload  
of the page makes it work the second time around. The ngnix error log  
shows  
this:

2012/12/19 15:50:43 [crit] 28799#0: \*6224 crypt\_r() failed (2: No such  
file  
or directory), client: 108.199.xxx.xxx, server: [dev.digitalpoint.com](http://dev.digitalpoint.com),  
request: “GET /admin.php HTTP/1.1”, host: “[dev.digitalpoint.com](http://dev.digitalpoint.com)”,  
referrer:  
“[http://dev.digitalpoint.com/](http://dev.digitalpoint.com/)”

It makes me wonder if maybe nginx worker processes can never read the  
auth\_basic\_user\_file the first time it tries for some reason (but always  
can  
after that first try)? Like I mentioned, it will work properly 100% of  
the  
time on a browser reload.

relevant part of nginx conf:

```
    location /admin.php {
            auth_basic Restricted;
            auth_basic_user_file /etc/nginx/.passwd;
    <...clipped...>
    }

```

/etc/nginx/.passwd exists and I assume everything is okay with it since  
everything works as expected on browser reload.

Anyone know how to fix this?

Posted at Nginx Forum:

> **[crypt\_r() issue when viewing HTTP auth page](https://forum.nginx.org/read.php?2,234214,234214#msg-234214)**
>
> When viewing a page that is HTTP auth password protected, we sometimes get an error 500 (internal server error), but 100% of the time, a browser reload of the page makes it work the second time around. The ngnix error log shows this: 2012/12/19...

---

<div class="post-metadata">

**Author:** ![digitalpoint](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/6a8cbe/32.png) [@digitalpoint](https://www.ruby-forum.com/u/digitalpoint)\
**Post date:** [December 20, 2012, 6:12pm UTC](https://www.ruby-forum.com/t/crypt-r-issue-when-viewing-http-auth-page/225200/2 "2012-12-20T18:12:40Z")

</div>

Hello!

On Wed, Dec 19, 2012 at 07:42:55PM -0500, digitalpoint wrote:

> It makes me wonder if maybe nginx worker processes can never read the  
> }
> 
> /etc/nginx/.passwd exists and I assume everything is okay with it since  
> everything works as expected on browser reload.
> 
> Anyone know how to fix this?

Try the following patch:

— a/src/os/unix/ngx\_user.c  
+++ b/src/os/unix/ngx\_user.c  
@@ -28,20 +28,15 @@ ngx\_libc\_crypt(ngx\_pool\_t \*pool, u\_char  
{  
char \*value;  
size\_t len;

- ngx\_err\_t err;  
struct crypt\_data cd;

- ngx\_set\_errno(0);

- cd.initialized = 0;  
/\* work around the glibc bug \*/  
cd.current\_salt[0] = ~salt[0];

- err = ngx\_errno;

- 
- if (err == 0) {

- if (value) {  
len = ngx\_strlen(value) + 1;

@@ -49,9 +44,11 @@ ngx\_libc\_crypt(ngx\_pool\_t \*pool, u\_char  
ngx\_memcpy(\*encrypted, value, len);  
return NGX\_OK;  
}  
+

- 

```
   return NGX_ERROR;

```

}

- ngx\_log\_error(NGX\_LOG\_CRIT, pool-\>log, err, “crypt\_r() failed”);

- ngx\_log\_error(NGX\_LOG\_CRIT, pool-\>log, ngx\_errno, “crypt\_r()  
failed”);

–  
Maxim D.

> **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)**
>
> Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises.

---

<div class="post-metadata">

**Author:** ![digitalpoint](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/6a8cbe/32.png) [@digitalpoint](https://www.ruby-forum.com/u/digitalpoint)\
**Post date:** [December 20, 2012, 8:34pm UTC](https://www.ruby-forum.com/t/crypt-r-issue-when-viewing-http-auth-page/225200/3 "2012-12-20T20:34:38Z")

</div>

Thanks… that patch seems to have fixed it. I haven’t done exhaustive  
testing, but if the crypt\_r()/internal server errors pop up again, I’ll  
post  
back here.

Posted at Nginx Forum:

> **[Re: crypt\_r() issue when viewing HTTP auth page](https://forum.nginx.org/read.php?2,234214,234277#msg-234277)**
>
> When viewing a page that is HTTP auth password protected, we sometimes get an error 500 (internal server error), but 100% of the time, a browser reload of the page makes it work the second time around. The ngnix error log shows this: 2012/12/19...