Been using Storage API for a while, was working fine. Recently relocated website to a new server on Amazon EC2 running on the Amazon Linux flavor. Now image uploads through Storage API fail.

Image uploads that don't go through a Storage API class, just uploading to Drupal default public files - SUCCEEDS
Image uploads through Storage API, whether to S3 or the Everything/Filesystem class and container - FAILS

I get the following error notices, and an Ajax error popup:

Warning: filesize(): stat failed for storage-field-test-image://example-file.png in file_save() (line 566 of /home/ec2-user/davidcsonka/includes/file.inc).

File removed: example-file.png
class: Everything,
storage_id: 91, file_id: 77, size: 94.56 kB

Failed to create initial instance of file example-file.png in storage container Filesystem.
class: Everything,
storage_id: 91, file_id: 77, size: 94.56 kB

Comments

davidcsonka’s picture

Update:

In my "S3" Storage Class, I updated it so that the initial storage container is no longer the "Filesystem" but rather the S3 Bucket container where the files will ultimately be stored.

After making this change, file uploads through Storage API appear to work successfully. So, some kind of problem with Storage API saving to the local file system. I'll have to double check to see if there is a permissions issue.

bennos’s picture

yeah same problem for me. After changing the initial upload container to S3 it works.
There is a problem with the file system as inital upload target.

lolascorpio’s picture

I could not get it to work locally from a fresh install, and found that the reason I was getting this error was that the file was being uploaded to my default/files directory and not the default/files/storage directory. Once I updated the path to just default/files in the FileSystem container settings , I managed to get this working locally. Next I will attempt to use local storage as my initial container with FTP as my external. Hope this helps someone!

perignon’s picture

Issue summary: View changes
Status: Active » Closed (cannot reproduce)

Is this issue still valid? It's been over a year but would need more information in regards to this.

masterperoo’s picture

yes, still a problem, keeps popping up - also on fresh install.
Everything seems in order - module authenticates on config pages, allows to create container and class.

Yet any attempt to save something using the class (i.e. image field) - fails
Warning: filesize(): stat failed line 601

perignon’s picture

Assigned: Unassigned » perignon
Status: Closed (cannot reproduce) » Active

@masterperoo Could you help me by giving me a steps to reproduce the problem. I would be grateful if you could!

DrupalHelpsMePowerNap’s picture

For what it's worth, I was able to recreate this issue by setting *all* of my containers to externally controlled, including the original internal filesystem container (I did this with an incorrectly-written script.) Changing the filesystem container back to non-externally controlled allowed me to upload the file without receiving an error. It might be nice (but not necessary) if there was a status report error/warning that alerts the user to all containers being externally controlled.

newsec’s picture

Have the same issue on fresh Drupal install when enabling external setting on filesystem storage. And why module don't use base url setting without external?

staphreak’s picture

I'm wondering if this was ever solved, I'm getting this error when trying to save to a directory outside of the Drupal instance.
I have 2 directories, one private and one public which I'm trying to save to. The directories are under "/opt/company_name/repos/private" and "/opt/company_name/repos/public". Both directories are owned by Apache. I receive the "Failed to create initial instance" error whenever I try to save an image to the public directory. I'm currently using Drupal 7.39 and Storage Api 1.6. I have tried 1.8 as well with same results.

jonhattan’s picture

"Failed to create initial instance" can be cause by several underlying issues. Using an absolute path is not one of them perse. Is there any other error in the watchdog and/or the php error log?

@staphreak, I'm missing in your report which is your configuration of containers, and which modules are you using (core_bridge or stream_wrappers).

staphreak’s picture

ok, sorry about that, I'm using the core_bridge module with 2 containers.
The first one is Private and set to Filesystem,
Access control = yes,
Status = Active
Classes = Private
Directory = /opt/company_name/repo/private

Second container is Public and set to Filesystem,
Access control = NO
Status = Active
Classes = Public
Directory = /opt/company_name/repo/public

For each image upload, I see 2 errors in the recent logs, the "Failed to create...." error and a "File Removed" error.
The message for the File Removed error is:
"File removed: R2D2.png
class: Public,
storage_id: 12, file_id: 5, size: 145.74 kB"

bluesky_still’s picture

same error