Update to 3.9.7.7 produces empty listing

File Away no longer supports using “..” in any base or sub path, per WordPress’s security requirements, so that won’t work. I agree the symlink isn’t a good solution.

I will take a closer look at the specifics of your situation when I get back to my desk.

In the meantime, can you verify what your Root Directory setting is set to. It should be set to Site Root.

Oh, I see you have the same site address and wordpress address url. That is not the same setup as the other issue from yesterday. I will set mine up that way when I get back and see if I can reproduce.

Yes, my Root Directory is set to “Site Root Directory”

Do you have an .htaccess in your root that forces all traffic to the wp directory? Is that how yours is set up?

Another question: go to your file away settings and delete everything from a base directory (or look at an empty one if they’re not all used). Dont save. Just tell me what the innermost directory is before you are able to start typing. Is it “domainname” or “wp”? Does it change when you change the Root Directory setting, hit save, and let it reload?

My root .htaccess does not rewrite all accesses to the wp directory, just the top level.

Redirect permanent /index.html /wp/

The innermost directory that I can’t edit is “wp”. The base dirs are all /home/username/dommainname/wp/

Changing the Root Directory to “WP Install Directory” does not change the Base Directories, or make them editable.

Ok so you just have a standard install. I cant figure out how you ever pointed back outside the wp directory in the first place, without using ..

Maybe I misunderstood. Were you always using a symlink and the symlink is no longer working?

I’m puzzled by that too. From backups, I see that I had a symlink in wp before, but somehow it disappeared.

The one in a recent backup points to ../files, so if you changed something to disallow following “..” in a path, that would have broken it. I don’t know what happened to the symlink itself, though. Perhaps I was mistaken about it being missing.

Since an absolute path in the symlink didn’t work, did you also disable following symlinks altogether?

I haven’t explicitly disallowed symlinks but perhaps indirectly by my use of realpath() to validate the path. Officially speaking, pointing outside the WP directory–either the install (which in your case is the only option) or where the domain is pointed (not your setup)–has never been supported. But I will play around with symlinks to see if I can find a clean way to do it. Are you using non-encrypted download links for your file downloads?

The site is https, so files get DL’d that way, but there’s no encryption of the links themselves.

All right. Thank you. I will see if I can come up with a solution.

I just submitted a new version… that one is not for you. FYI

Hey, @stoneyb. I’ve got a symlink fix that is working for me with encryption both enabled and disabled. I still use realpath, but if the realpath doesn’t equal the specified path, then I iterate through the specified path to see if at any point there is a symlink. If there is a symlink, I check to see if the symlink target plus whatever child directories beyond the symlink are specified equal the realpath.

Kind of like this:

/realpath/to/files
/realpath/to/wp/symlink

Base_1 = /realpath/to/wp/symlink/newsletters

realpath(Base_1) will equal /realpath/to/files/newsletters

So if Base_1 does not equal realpath(Base_1), I do the following:

Is /realpath/to/wp/symlink/newsletters a symlink?

The answer will be NO because newsletters is not a symlink.

So then I ask: Is /realpath/to/wp/symlink a symlink?

In this case, then answer will be yes. So if I get a yes, I then do:

Does the target of /realpath/to/wp/symlink + /newsletters equal /realpath/to/files/newsletters. If yes, you get a pass. If no, you get a fail.

And it’s working for me.

Give me a few minutes to commit the new version and I’ll let you know when it’s up.

What is the problem just using realpath() directly? I assume that’s what you used to do. Some sort of security problem?

I’ll try the upcoming new version and let you know.

3.9.7.9 is now up.

The issue is when you’re using a symlink, the path to the symlink is not the same as the path to the target, and realpath() returns the path to the target. My new security checks make sure that the path provided to the file display function does not differ in any way as a string literal from the realpath() of the path provided. That was causing symlinks not to work. (It will also cause “..” not to work, but that is intentional and will not be changed.) I’ve now updated the function to check if there is a symlink involved if the path provided does not equal the realpath().