XF 2.1 Change folder store attachment

hanyuwomr

Member
Hi,
We have an issue with folder store attachment then I want to change location, How can I change it.
I tried with config :
$config['externalDataUrl'] = '/mnt/disk/data/attachments';
$config['externalDataPath'] = '/mnt/disk/data/attachments';
but it seem not running. File uploaded but i can't see any file in folder of /mnt/*.
Please help me.
Thanks.
 
I don't use ANY of the above suggestions. I use nginx and I use a simple
Code:
location /internal_data/ {
    root /mnt/path_to_mount_location/internal_data;
    }
settings in my site nginx config file... I also DO have symlinks set up in the site base location so that my backup script will pull in the files in those locations when it runs without having to do any "magic" to get it to back up those also, which are stored in a Digital Ocean volume mounted to the VPS.
It all seems to run fine.
 
Last edited:
This is most certainly unnecessary and potentially dangerous; internal_data shouldn't be accesssible via HTTP.

If you have a symlink in place that can be followed by PHP that's all you need.

See https://xenforo.com/community/threads/externaldatapath-externaldataurl.207328/
The problem is, nginx is configured to specifically NOT allow outside the root when using CentMiinMod (which I use)... so by allowing THAT specific path, you are doing no more than you do when it's in the root directory as it's restricted to the root defined location ONLY. It is NO different than having /internal_data available via the root. You are simply extending the root destination to a folder outside the base, and THAT folder only. The ownership/rights are STILL controlled as if it was in the root location. In fact, having a simple symlink would be a bigger issue than this.
Anyone that has their HTTP server set up to follow symlinks willy-nilly is simply showing sheer stupidity and a pure lack of knowledge of safely setting up an HTTP server exposed to the internet. Even though I have symlinks set up in the local directory pointing a those separate points for local backup purposes, they are unreachable by HTTP since there exists a separate route defined for them that bypasses the symlinks in the nginx config file.
 
Last edited:
It is NO different than having /internal_data available via the root. You are simply extending the root destination to a folder outside the base, and THAT folder only.
Unless you have specific requirements (like using X-Accel-Redirect), internal_data should not be accessible via HTTP, no matter if it is within document root or not.

Even though I have symlinks set up in the local directory pointing a those separate points for local backup purposes, they are unreachable by HTTP
Some of them are accessible if requests are sent directly to the origin (by bypassing CloudFlare which is rather trivial as your server is leaking the origin IP).
 
Some of them are accessible if requests are sent directly to the origin (by bypassing CloudFlare which is rather trivial as your server is leaking the origin IP).
Considering I'm not using CloudFlare for "hiding" the IP, that's not a big concern of mine. I'm using it more for the other capabilities it offers.

Utilizing the internal; directive should be restricting any direct outside access to the directories... if it's not, then there is a bug in nginx.
And considering there are multiple sites, simply going by the IP to the location gets you the server config for that IP.. which is NOT the forum site. Feel free to browse to that IP and you will see that it doesn't resolve back to the forum. ;)
 
Utilizing the internal; directive should be restricting any direct outside access to the directories... if it's not, then there is a bug in nginx.
The configuration snippet you posted in https://xenforo.com/community/threads/change-folder-store-attachment.177691/post-1594280 doesn't show you are using internal.

Using internal is okay, but if you don't need internal access (which normally isn't necessary) I would even block internal access.

It might be a bug that certain external requests are still possible, but it's more likely a configuration issue.

I don't know your exact setup, but I'd assume it's smth. like
Code:
server
{
    listen 443;
    server_name astrowhat.com;
    
    location / {
        try_files $uri $uri/ /index.php?$uri&$args;
        index index.php index.html;
    }

    location /internal_data/ {
        internal;
    }

    location /src/ {
        internal;
    }

    location ~ \.php$ {
        # pass to PHP-FPM
    }
}

This configuration does still allow external access to /internal_data/*.php.
This is normally not a thaat big issue, but I'd block that as well - better safe than sorry.
 
doesn't show you are using internal.
Yep... I had to clean up the config... I had it being done in an include file... but figured it's cleaner to do it all in the site config file itself as that way if I have to recreate a VPS it may be easier the next time. This convo reminded me I needed to move it from that include file as having the same location in two different calls could cause issues. ;)
I normally try to document the config files as I modify them, but the script little script I had written to modify the files didn't do that... and since that config file was one that was created on a new VPS the very day it was posted, I hadn't gone through and cleaned it all up as I was still working on getting the sites back up and running. I had "ass-u'med" that CentMin did the MariaDB updates when you did the rest of the system... but it's excluded and you have to manually run updates...and the site was on MariaDB 10.1. Only problem... the repositories for 10.1 & 10.2 are not there any longer apparently and when you used the CentMin update process... you suddenly had no working MySQL setup as you have to progress through each one to reach 10.3.

But it's standard for anyone setting up nginx they ened to have certain directories listed as internal either in their site nginx file itself or via an include directive.

Actually, the fully relevant section that's now been included in the astrowhat config file is
Code:
location /images/ {
  root /bucket_location/images;
  internal;
   }

location /install/templates/ {
    internal;
    }
location /src/ {
    internal;
    }

location /my_symlink/ {
    deny all;
     return 403;
}
location /my_symlink2/ {
     deny all;
     return 403;
}
location /my_symlink3/ {
      deny all;
      return 403;
}
 
location /data/ {
   root /bucket_location/data;
   add_header Cache-Control "public, max-age=31536000";
   internal;
      }
location /internal_data/ {
    root /bucket_location/internal_data;
    internal;
    }

location /js/ {
    add_header Cache-Control "public, max-age=31536000";
    }
location /styles/ {
    add_header Cache-Control "public, max-age=31536000";
    }
location /favicon.ico {
    add_header Cache-Control "public, max-age=31536000";
    }

If you are familiar with CentMin Mod you should be familiar with the way it processes.
There is an include for php.conf, which uses this
location ~ [^/]\.php(/|$)

I've toyed with using a
Code:
deny all;
return 403;
in those locations that use internal for the out of root locations to just see if it still worked.
 
Last edited:
Example:

PHP:
$config['internalDataPath'] = '/home/username/public_html/xenforo/internal_data';
$config['externalDataPath'] = '/home/username/public_html/xenforo/data';
$config['externalDataUrl'] = 'https://www.domain.com/xenforo/data';
I just want to move the internal_data folder to another directory.

if i use this code in config settings ''$config['internalDataPath'] = '/home/username/public_html/xenforo/internal_data';''
i get white screen error
 
Top Bottom