Directory Listing empty after upgrade to 0.9.44

[TiKu]

Hi,

I have been using version 0.9.43 without any problems. When connecting to the server, the client successfully received the directory listing.
Then I upgraded to version 0.9.44 and now the client connects successfully, but always receives an empty directory listing. I noticed that the upgrade did reset all aliases, so I reentered them, but this didn't help.
The problem exists even on localhost and I did not change the firewall or router config. Therefore I'm sure it is an issue with FileZilla Server or its config.

Here is the client log:

Status: Auflösen der IP-Adresse für localhost
Status: Verbinde mit [::1]:21...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort: 220 FileZilla Server version 0.9.44 beta written by Tim Kosse (Tim.Kosse@gmx.de) Please visit http://sourceforge.
Befehl: USER Kunze
Antwort: 331 Password required for kunze
Befehl: PASS ********
Antwort: 230 Logged on
Befehl: SYST
Antwort: 215 UNIX emulated by FileZilla
Befehl: FEAT
Antwort: 211-Features:
Antwort: MDTM
Antwort: REST STREAM
Antwort: SIZE
Antwort: MODE Z
Antwort: MLST type*;size*;modify*;
Antwort: MLSD
Antwort: AUTH SSL
Antwort: AUTH TLS
Antwort: PROT
Antwort: PBSZ
Antwort: UTF8
Antwort: CLNT
Antwort: MFMT
Antwort: 211 End
Status: Verbunden
Status: Empfange Verzeichnisinhalt...
Befehl: PWD
Antwort: 257 "/" is current directory.
Befehl: TYPE I
Antwort: 200 Type set to I
Befehl: EPSV
Antwort: 229 Entering Extended Passive Mode (|||49180|)
Befehl: MLSD
Antwort: 150 Opening data channel for directory listing of "/"
Antwort: 226 Successfully transferred "/"
Status: Anzeigen des Verzeichnisinhalts abgeschlossen

And the server log:

(000003)02.05.2014 08:40:49 - (not logged in) (::1)> Connected, sending welcome message...
(000003)02.05.2014 08:40:49 - (not logged in) (::1)> 220 FileZilla Server version 0.9.44 beta written by Tim Kosse (Tim.Kosse@gmx.de) Please visit http://sourceforge.
(000003)02.05.2014 08:40:49 - (not logged in) (::1)> USER Kunze
(000003)02.05.2014 08:40:49 - (not logged in) (::1)> 331 Password required for kunze
(000003)02.05.2014 08:40:49 - (not logged in) (::1)> PASS ********
(000003)02.05.2014 08:40:49 - kunze (::1)> 230 Logged on
(000003)02.05.2014 08:40:49 - kunze (::1)> PWD
(000003)02.05.2014 08:40:49 - kunze (::1)> 257 "/" is current directory.

So in the logs everything seems correct.

What could be the problem?

[botg]

Is the home directory by change located on a mapped network resource?

Did you in the past change the user account the server service ran under?

[TiKu]

No and no.

[botg]

Befehl: USER Kunze
Antwort: 331 Password required for kunze

Could it be related to character case? Try logging in with kunze. What's the capitalization of that user as configured in FileZilla Server?

Is kunze part of a group?

[TiKu]

Ok, I'll check tonight.
The user is member of a group, yes. I'll check whether the problem also exists if the user is not member of a group and is configured individually instead.

[feenyx360]

I have also experienced improper directory listing after upgrading to 9.44. Users, where members of a group with defined shared folders, some folders don't appear in the directory listing. I have an alias directory path for the user (several of them defined via group) which work but any directory added with a non-alias path such a c:\ftp\test\ does not show up when logging in with the user. The same goes for users outside of a group. Any path with the u: alias works but non-alias paths do not.

In addition, after removing alias directories defined in the user and adding non-alias directories, the alias directories appear to stick around as I can access them after removal. This is very funky behavior and I have had to remove and re-add an account in order to remove access to alias directories which were removed from the user.

The only way to add a non-alias directory after messing around with an account was to delete the user entirely and add a non-alias path and that's it. The remaining problem then is that the user doesn't have access to there alias directories.

[TiKu]

Befehl: USER Kunze
Antwort: 331 Password required for kunze

Could it be related to character case? Try logging in with kunze. What's the capitalization of that user as configured in FileZilla Server?

Is kunze part of a group?

The user is configured as "Kunze", so it's the same capitalization as is used for login. I played with the capitalization, but i didn't help.
I also tried removing the user from the group and configuring it individually instead - no improvement. Then I removed the user and created a new one (not member of any group): no improvement.

[Cypress]

Hi,

I have been using version 0.9.43 without any problems. When connecting to the server, the client successfully received the directory listing.
Then I upgraded to version 0.9.44 and now the client connects successfully, but always receives an empty directory listing. I noticed that the upgrade did reset all aliases, so I reentered them, but this didn't help.
The problem exists even on localhost and I did not change the firewall or router config. Therefore I'm sure it is an issue with FileZilla Server or its config.

Is the user's Home-directory empty?

Regarding the aliases in 0.9.44 support for the old non-virtual alias configuration has been removed. Meaning "C:\FTP\Something" is no longer a valid alias. A valid alias would be "/Something" or what ever you want the directory to appear to be named when the user connects.

[TiKu]

Yes, the home directory is empty.
The removal of the non-virtual aliases explains what I see. I changed them to virtual aliases, and now it's working. Thank you!

[botg]

Odd, there should have been an error message if trying to enter aliases using the old syntax. I'll fix that bug.

[boco]

Does that mean the silent deletion wasn't intended? That's what will confuse users when updating.

[botg]

Removal of old alias syntax has been in the release notes. What is unintended is that you can still recreate aliases using the old syntax, which then do nothing.

[krypt0n]

Filezilla actually displays the old help message when editing the alias for existing entries. Only after removing all old-style entries and re-adding the shared folders does the help message for alias editing change to the new one.

Also, I really don't see a reason why we must set a home directory manually. Couldn't filezilla figure out that if no home directory is set and the directory list only has virtual directories to use an empty directory?

So if you have like
C:\DATAFOLDER1 > /Folder2
C:\DATAFOLDER2 > /Folder3

Filezilla requires a home folder to be set

So you need to setup it like this:
C:\EMPTY (Home)
C:\DATAFOLDER1 > /Folder2
C:\DATAFOLDER2 > /Folder3

Instead Filezilla should just list
Folder2 and Folder3 at /
without the need of an empty home folder if none is set

Also, if you add a shared folder, but cancel it, there's a <new directory> added to the list and Filezilla bitches about it not being set when pressing OK instead of just ignoring it like it should.

[botg]

For normal users there's an error message if no home directory is set. It might even be set automatically, I can't remember. This intentionally doesn't happen when the user is part of a group. Group configuration can be very complex, adding error message would make workflows with groups even more complicated than they already are.

[boco]

I'm one of the very few who actually read changelogs. This time I missed it.

@botg: On the Shared folders[sic] page, there's still the following help statement: "Aliases must contain the full local path". How should that to be understood?