As of DNN 7.6 the journal shows considerable promise in enabling and building a robust social community. One of its major drawbacks is that files and images uploaded through the journal get saved in the web server Portal/Users folder. As a result a robust and active community that uploads images and files can quickly overwhelm the expensive storage capacity of hosted DNN websites and portals.
The simple fix for this is to go to your journal module instances and turn OFF "Enable File Attachments" and "Enable Photo Attachments."
There are several reasons to make file and photo attachments DISABLED. One is that the Journal files are saved in the Portal/Users folder, which cannot be successfully mapped to a cloud storage provider like Amazon S3 or Microsoft Azure. The journal uses an API that creates User folders on the fly so even if you successfully move the existing folders and content of the Portal/Users folder to the Cloud any time a new user is created and they upload a file via the Journal the API will create a new folder on your local file system and try store files on your local web server instead of the cloud. This is because the Journal API doesn't use the standard DNN file system methods for creating folders and accessing files.
Second, because the journal doesn't use the standard File System methods users cannot add new files through the journal if the Users folder is mapped using a cloud provider. User can attach files that already exist in the folder, but this requires admin intervention to get the file(s) via ftp or the DNN file manager. I don't think a DNN admin wants to upload score, hundreds or potentially thousands of files and photos for users via FTP or the DNN file manager.
Third, the journal doesn't store attached file locations using the standard LinkClick url. This means that any files that are somehow saved to the journal it will never migrate successfully to the cloud. Any time a user clicks on an image or file link the Journal will try to refer to the local copy instead of the generic LinkClick mapping which supports cloud migration. This means that even if you can allow users to add files and then find out you are running out of space, you won't be able to migrate the existing journal to a cloud provider. The Journal will always look for the old files or photos in the local file system, so old images won't display correctly and old file links will be broken in the journal.
The file location path is saved using a physical path instead of a flexible DNN URL that uses the LinkClick method. This is somewhat odd because the HTML module uses the LinkClick method for showing the path to the file, but the Journal module does NOT use the LinkClick method, so Custom folders and files uploaded via the HTML module can migrate to the cloud without issue but the Journal files won't and/or entries cannot be migrated to the cloud without significant SQL scripting to update legacy journal photo and file paths..
DNN is a GREAT solution and the social features are pretty darn cool. It would be nice to see the journal support social features that have long been available in many social sites.
So... save yourself some grief and turn OFF File Attachments and Photo Attachments in all of your journal module instances. Someday, and hopefully in the near future, the DNN Journal and its API will support proper cloud storage integration, either natively or through existing 3rd party modules. Until then play it safe, save some money and keep your users Journal postings limited to text and links.