The FTP-only username is ftpuser in the following instructions.
1. su to root
2. # cat /etc/passwd|cut -f 1 -d: > /etc/ftpusers
3. # echo 'echo "FTP user"' > /bin/ftpuser
# chmod a+x /bin/ftpuser
4. If /etc/shell exists, add
/bin/ftpuser
to the last line.
If not
# ls /bin/*sh > /etc/shells
Then add /bin/ftpuser to the last line
5. # useradd -c "FTP User" -d /export/home/ftpuser -m -s /bin/ftpuser -g staff ftpuser
6. # passwd ftpuser
Source: http://www.tek-tips.com/faqs.cfm?fid=2315 + my modifications.
Added on 6/9/2010: I just found that my full access account couldn't ftp any more after this. Only ftpuser can ftp. For some strange reason, my username got added to /etc/ftpusers which lists the users that can NOT ftp... Very very weird. After removing my username, the ftp works again.
Tuesday, June 8, 2010
Friday, June 4, 2010
gconf problem
Yesterday for some reason my CentOS 5.3's gnome session couldn't start any more. It kept showing this kind of messages:
"An error occurred while loading or saving configuration information for gnome-session. Some of your configuration settings may not work properly.
An error occurred while loading or saving configuration information for Nautilus. Some of your configuration settings may not work properly.
An error occurred while loading or saving configuration information for Power Manager. Some of your configuration settings may not work properly.
.
.
."
Clicking on "Details" showed:
"GConf error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Could not send message to gconf daemon: Message did not receive a reply (timeout by message bus))"
This morning I spent hours trying to figure out what's going on here. Reinstalling is the last resort. Creating a new user and copy all the files under it is a workaround.
Finally from one of the numerous posts I read, I found "messages" file under /var/log could give you some clues if the system encounters problems during the process of starting up.
The last part of my messages file showed:
Jun 4 04:08:18 mboot-dell gconfd (root-10001): starting (version 2.14.0), pid 10001 user 'root'
Jun 4 04:08:18 mboot-dell gconfd (root-10001): Bad permissions 777 on directory /tmp/gconfd-root
Jun 4 04:08:18 mboot-dell gconfd (root-10001): Failed to get lock for daemon, exiting: Directory /tmp/gconfd-root has a problem, gconfd can't use it
It turned out that the directory /tmp/gconf-xxxx has to have permission 700 instead of 777 where xxxx is the user name. I must have changed it to 777 while doing one of my scribed tests.
Can you believe that? The success of starting the GNOME session depends on the permission of the directory in /tmp directory! This is really hard to conceive. /tmp should be used as /tmp not as a place to save anything mission critical. Don't you think so?
"An error occurred while loading or saving configuration information for gnome-session. Some of your configuration settings may not work properly.
An error occurred while loading or saving configuration information for Nautilus. Some of your configuration settings may not work properly.
An error occurred while loading or saving configuration information for Power Manager. Some of your configuration settings may not work properly.
.
.
."
Clicking on "Details" showed:
"GConf error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Could not send message to gconf daemon: Message did not receive a reply (timeout by message bus))"
This morning I spent hours trying to figure out what's going on here. Reinstalling is the last resort. Creating a new user and copy all the files under it is a workaround.
Finally from one of the numerous posts I read, I found "messages" file under /var/log could give you some clues if the system encounters problems during the process of starting up.
The last part of my messages file showed:
Jun 4 04:08:18 mboot-dell gconfd (root-10001): starting (version 2.14.0), pid 10001 user 'root'
Jun 4 04:08:18 mboot-dell gconfd (root-10001): Bad permissions 777 on directory /tmp/gconfd-root
Jun 4 04:08:18 mboot-dell gconfd (root-10001): Failed to get lock for daemon, exiting: Directory /tmp/gconfd-root has a problem, gconfd can't use it
It turned out that the directory /tmp/gconf-xxxx has to have permission 700 instead of 777 where xxxx is the user name. I must have changed it to 777 while doing one of my scribed tests.
Can you believe that? The success of starting the GNOME session depends on the permission of the directory in /tmp directory! This is really hard to conceive. /tmp should be used as /tmp not as a place to save anything mission critical. Don't you think so?
Subscribe to:
Posts (Atom)