530 User xxxxx may not use FTP.

Did you enter the right password?

The error means "530 Login incorrect."

Are there spaces in the user name?

With "right password" I mean UPPERCASE/lowercase too.

Try revoking the access to the user, press ok, wait for it to stop thinking and granting the access once more...

What kind of user for FTP did you setup? Is this a regular account local or network? If it's local, is it services only with no home directory?

The picture isn't available for us to see, please submit the picture again using the insert image dialogue when replying to my message.

I just want to confirm how to fix that.

Apple Server app -> Accounts/Users -> Advanced Options in the context menu for the user -> Login shell

It is /user/bin/false by default for "Services only" account, should be changed to /bin/sh

Acidron wrote:

It is /user/bin/false by default for "Services only" account, should be changed to /bin/sh

Yeah "/user/bin/false" is the default for Services only accounts/users, and it needs to be changed. While I didn't verify them all, any of the listed shells should work. I set mine to /bin/bash months ago and never had a problem.

I think this only works for local "services only" users/accounts since they're the only ones that will appear in the Users&Groups System Preferences for editing.

Acidron wrote:

I just want to confirm how to fix that.

Apple Server app -> Accounts/Users -> Advanced Options in the context menu for the user -> Login shell

It is /user/bin/false by default for "Services only" account, should be changed to /bin/sh

Thanks !

Actually, while this will work, it is NOT the appropriate way to deal with this from a security point of view.

Let me explain. The real reason why you are seeing the "User xxxxx may not use FTP" message is for the following reason. In *nix based systems such as Mac OS X, when you create a user, that user has a login shell associated with it as already mentioned (right-click a user and select 'Advanced Options...' to see this). This shell is usually something like a Bourne Again SHell (BASH) (/usr/bin/bash), C SHell (/usr/bin/csh), or your more traditional Korne SHell (/usr/bin/ksh), depending what the user prefers to use for their command line.

However, when you setup a Mac user with the Home Folder: set to [None - Services Only], you are indicating that this user is to have access to some set of services such as FTP but NOT be a local user on the machine (as in you see that user on the login screen and can sign in with their credentials right on the Mac). Therefore, such a user's login shell is set to /usr/bin/false. Translation: this user does not HAVE a login shell, therefore cannot login. If they attempt to TELNET/SSH/etc., as the process continues, the lack of a shell will deny them access. This is by design.

Unfortunately, for whatever reason, Apple neglected something. Also in *nix-based systems, there are system files located in the /etc/ folder which determine various things. One of those files is /etc/shells. As you can see if you bring up a Terminal and enter the following commands:

cd /etc

cat shells

here is what is in that file, and the comments explain its purpose:

____________________________________________________________

# List of acceptable shells for chpass(1).

# Ftpd will not allow users to connect who are not using

# one of these shells.

/bin/bash

/bin/csh

/bin/ksh

/bin/sh

/bin/tcsh

/bin/zsh

____________________________________________________________

So what's my point? Look carefully at that file. Notice anything missing? That's right. There's no line reading

/usr/bin/false

This means that although the Mac GUI let you create a "services only" user, they associated that user with a "shell" which is not in the approved /etc/shells list. THIS is why you are being rejected. Why Apple didn't include this is beyond me.

Now Acidron's solution works because you are changing the login shell to one that IS listed in /etc/shells. But you are ALSO giving that user an ACTUAL login shell, which might be misused to gain higher level access to the system.

The RIGHT solution would be for Apple to include the missing line in /etc/shells. But as they have yet to do it, you can do it yourself. Using Terminal, simply edit this file as root and add the one line, doing something like this:

sudo vim /etc/shells

If you are not familiar with the VIM editor (quite possible), I'd suggest an easier one that's built-in as well. Do this instead:

sudo nano /etc/shells

You should be prompted for your password (what you used to log in to the Mac and/or any time you install Mac software and it wants your password). Enter it, and at this point you'll be in the nano/pico editor with the file contents loaded. Simply use your cursor keys to navigate to the bottom of the file, enter the one line

/usr/bin/false

then save the file by pressing [CTRL]-[X] and then hitting [Y] to confirm the save.

As a few added things to note, the FTP server built into Mac OS X also looks for other files in /etc. For example, if you want a welcome message to be shown, simply create the file

/etc/ftpwelcome

And on my systems in the past I tended to create the file

/etc/ftpchroot

in which I placed the usernames I allowed to FTP into my box, as it would change their root directory to their home directory (before OS X offered this "services only" option). This prevented them from "breaking out" and seeing more of the file system than necessary.

Worked like a charm. Thanks

Thanks. Ran into the same problem myself tonight.