Filesystems, Disks and Memory

OS red hat 7.3

I deleted a user using webmin and while I was there I browsed around a bit. I didn't think I changed anything but....

http://rhinoseros.com/~pics/temp/webmin.gif

Now I can't upload a file except as root. In ssh file transfer I get "Transfer failed with error8: file.zip Undefined error occurred." Ftp just says error, trashed response.

Any clues? Thanks.


edit. I just disovered I can run perl/cgi scripts from the server root but not from users. I could before, but not anymore.

Directory permissions 'appear' to be correct.

I've been searching but still haven't come up with the answer yet. However, this page sounds close http://www.perl.com/doc/FAQs/cgi/idiots-guide.html

Q: Under what uid does the server runs its CGI programs?
A: wwwuser (Oops, it can't write my files or directories.)

The author's flippant tone may amuse those in the know, but it doesn't help me one bit. How would one go about correcting this. Is it even in the right direction for what I described above? It associates uid with writing files, so it seems if not on target then at least relevent.

When you make a mistake like this you need to 'stop thinking GUI' and get to the command line:

(1) What is the user ID your web server runs when users are connecting? Hint:

Code:

ps aux | grep httpd

(2) Does this user ID have executable permissions for the PERL or other CGI scripts?

(3) Does this user ID have read permissions into the HTTP document tree?

These are the things that the author of your cryptic note were trying to point out, and when you have these types of problems, you must 'leave your GUI' on the sidelines and learn to navigate the shell and use basic shell commands like cd, ls, pwd, find, chmod, chown, ps, grep, more and do some snooping around the fun and friendly filesystem.

FWIW: In over 15 years of UNIX and Linux work, I've never used a tool like Webmin.... it is just too much fun and a lot faster (when you get used to it) to command the shell !!

Thanks for the response, Neo

>>When you make a mistake like this you need to 'stop thinking GUI' and get to the command line:

I didn't use for nothing. I should've known better. But it's spilt milk. I'm looking for the mop.

>>(1) What is the user ID your web server runs when users are connecting? Hint: ps aux | grep httpd

ps - process status
aux - all interesting user oriented and no terminal processes (I think)
| pipe it to
grep - get regular expression print
httpd - match this pattern

http://rhinoseros.com/~pics/temp/psauxgrephttpd.gif

But it's still just so many numbers to me.

>>(2) Does this user ID have executable permissions for the PERL or other CGI scripts?

I don't know and I don't know how to find out.

>>(3) Does this user ID have read permissions into the HTTP document tree?

ditto.

>>These are the things that the author of your cryptic note ...

I understand that, but it puts me no closer to solving the problem.

>>FWIW: In over 15 years of UNIX and Linux work, I've never used a tool like Webmin.... it is just too much fun and a lot faster (when you get used to it) to command the shell !!

For what it's worth, I used DOS 3.3 until 1998. I did not do any networking. Earlier this year, I saw webmin in a lab setting and was not impressed. A friend is taking a course and they are stressing webmin a lot. I just bought into a dedicated server after practicing at home for a few months and the company installed webmin so I thought I'd have a look. I should've known better cuz now it's screwed things up. Running the web server and troubleshooting scripts is all well and good but it still doesn't explain to me why other read/write problems exist in ssh or ftp situations. I have no phobia with command lines nor shells. I'll add, I like unix/linux as a concept but "useful" information is just plain and simple too hard to come by.

Thanks Neo, I hope you can point me to the next step.

Okay, I got it. df -k show'd me the partition for /home/ was too small so I ran out of space even tho the hdd was no where near capacity yet. Then webmin removed ExecCGI from the directory line in httpd.conf, and made a few other changes that were hard to spot. In short, I'm back in business.