FileZilla Forums

I have 2 users on my FilleZilla server ... version 0.9.60 beta,

One is suddenly reporting that he is getting 550 Permission denied

When I log in as me, I have no problem.

I have compared the two Shared folders screens; they are the same.
Attached are three screen shots.
1) My screen
2) His screen
3) Log file

What am I doing wrong?

I did read other postings similar to 550 on your board but they did not seem to match.

Regarding the STOR operation failing, does the file in question already exist on the server? For writing files to the server, you only need Write permission, but to overwrite files on the server, you also need the Delete permission. Technically, overwriting is delete followed by write.

OMG!! Thank you. That did it!
I need to buy glasses ... I didn't spot that. Should've.

Hallo,

we are using version 1.6.1 and get this error message.
In older version (like 0.9xx) there was a possibility to allow or deny List command. In version 1.6.1 I cannot find this setting.
May I have overseen this or what could be root cause of

2023-01-10T15:52:27.688Z >> [FTP Session 11424 10.32.254.14 708] LIST *.*
2023-01-10T15:52:27.688Z << [FTP Session 11424 10.32.254.14 708] 550 Permission denied

We are at 1.6.5.

List commands are denied on "Disabled" setting for the resource, but so are all Read and Write commands. Specifically denying List commands was never supported (doing so in 0.9.x would make the directory unavailable).

The error shown here has nothing to do with it. LIST in FileZilla Server 1.x follows the official implementation, which doesn't support any wildcard character. Use only "LIST", not "LIST *.*".

boco wrote: ↑

2023-01-23 17:16

The error shown here has nothing to do with it. LIST in FileZilla Server 1.x follows the official implementation, which doesn't support any wildcard character. Use only "LIST", not "LIST *.*".

Thanks for info.
Where can I find official docu, that List command should not support any wildcard?

RFC 959. Enjoy studying it. Follow it up with RFC 3659 which is the far superior alternative to LIST.

Thank you for reply.

If the pathname specifies a directory or other group of files, the server should transfer a list of files in the specified directory.

From my point of view, bold marked text means, that wildcard can be used. How otherwise can group of files selected?

Background.
We built machines and access is via ftp only, because software is very old (at least 10 years).
So our customers were using Filezilla server 0.9.xx and List command with wildcard was working. Later they updated to 1.xx and obviously it is no more working.
They have to find an alternative, if wildcards are no more allowed.
Software of controller cannot be changed anymore.
Do you have another idea?

No, it does not mean wildcards can be used. It doesn't even specify a globbing syntax including the necessary escapement scheme. The wording in the RFCs refers to other groups of files such as folders, volumes or drives. Things that themselves would appear in the LIST output if it had not been given an argument.

It was a mistake to ever add wildcard stuff to the old FileZilla Server. If I could, I'd go back in time to ensure it was never added to begin with.

The solution is to update the clients to not use wildcards in command-arguments and to instead filter the listings themselves.

Thanks or reply.
As we cannot change software on our controller, our customers have to use either old version or change to other ftp server. At the moment I test with servu and there are no problems with wildcards. Possibly servu interprets RFCs differently.

Why can't the software be changed?

botg wrote: ↑

2023-02-01 15:11

Why can't the software be changed?

Software for such modules is very old. Therefore it is not possible to change software.

I made further tests with linux server "vsftpd under Ubuntu 20.04 LTS". It seems, that our "old" software is also working.