What permissions are necessary?

I went back over my setups and resubmitted a few tests while conscientiously noting what happens and studying the web logs, the state of the DB, and the resulting emails and files. It all comes down to Internet Explorer and, I suspect, how it works with JQuery. I had been using IE 8 in Compatibility Mode, since we work with a lot of government agencies and they use IE almost exclusively, and very often older versions, and I have to make sure stuff works for them. However, in that state, it seems not to work.

At some point my IE crashed during a test and I decided to check it with a Member account in Safari, as I just happened to have it open. That worked. I tried again with IE 8 in regular mode, and it worked. What's weird is that in either version of IE, the form looks like it works; you can select multiple files, it builds the list onscreen, they are removable, etc. It's only when you click Submit does it fail, but it doesn't give any indication of failure. It comes through the Post process either with an empty value or it's not recognized by the Webform code as something it should stick in the File component. Don't know enough about how it's putting together the different modules to go further, but hopefully this is useful info.

Safari, Chrome, and Firefox all worked when logged in as a Member.

This is the file input in IE8 as seen using the IE Developer Tool view (the Webform field key is "multiple_attachments"):
<input name="files[multiple_attachments][]" class="form-file form-item multi MultiFile-identifier-multiple-attachments MultiFile-applied" id="edit-multiple-attachments" type="file" size="60" MultiFile="[object Object]" jQuery1344268046973="5"/>

And here it is in IE8 with compatibility mode:
<input name="files[multiple_attachments]" class="form-file form-item multi MultiFile-identifier-multiple-attachments MultiFile-applied" id="edit-multiple-attachments" submitName="files[multiple_attachments]" type="file" size="60" MultiFile="[object Object]" jQuery1344268432019="5"/>

The raw source code in either state of IE, as well as Chrome and Firefox, doesn't have the extra [] on the name, so I assume that's the client-side change you're referring to. Using Chrome or Firefox's "Inspect Element" tool it also shows it with the extra square brackets. But IE8 in compatibility mode is missing them. It's also got this extra "submitName" attribute that neither regular IE8 nor Firefox show.

A lot going on here. I've installed the dev module and now when I try submitting my webform, I get a 500 error. Server error log shows this message:
[Wed Aug 08 11:22:24 2012] [error] [client 10.1.3.136] PHP Fatal error: Unsupported operand types in /var/www/xyz.org/sites/all/modules/webform_multifile/multifile.inc on line 502, referer: http://xyz.org/content/claims-notice-submission-form

I looked at the code that is throwing the error, and it looks OK to me. I've tried making some simplifications to the code, making the string substitutions more direct, still get the same error. I tried doing the filesize calculation on a separate line beforehand:
$intsize = (int)($size/1024);
and it throws the same error on that line. I guess at that point $size is not something that can be divided. I tried adding in a line to print out the values of $key and $size in that loop but I guess the error prevents it. So I then took the $filesize calculation out and just assigned a hardcoded value. That allows it to process. My diagnostic code then shows KEY = 0 and SIZE = Array. Further print_r'ing the $size array shows:

Array
(
    [multiple_attachments] => 1385
)

The 1385 is apparently the file size in bytes, but it's not being accessed correctly. I don't see yet how to tweak it to get the webform element key and use that as the array key there to get that value.

Ensuring the $size variable is an integer makes the 500 error go away, but it stops accepting the form altogether. When the page loads, it will show the form with the previous data prefilled and the Multifile field highlighted in red, as if it's a required field, although it's not, according to the Webform design. This happens if I select zero or more files for attachment.

Further, the new module results in further errors/warning on the screen. Following submitting the form originally, I would hit F5 on the page, and it comes back with the form but these items in the error div at the top of the page:

warning: strrpos() expects parameter 1 to be string, array given in /var/www/xyz.org/sites/all/modules/webform_multifile/multifile.inc on line 491. 
warning: mb_substr() expects parameter 1 to be string, array given in /var/www/xyz.org/includes/unicode.inc on line 478. 
Files with the '' extension are not allowed, please upload a file with a gif, jpg, png, bmp, eps, tif, psd, txt, rtf, odf, pdf, doc, docx, ppt, pptx, xls, xlsx, xml, avi, mov, mp3, or wav extension.

That's what I see when I try submitting the form with either zero or one attachment. I tried again with three attachments and got this:

warning: strrpos() expects parameter 1 to be string, array given in /var/www/xyz.org/sites/all/modules/webform_multifile/multifile.inc on line 491. 
warning: mb_substr() expects parameter 1 to be string, array given in /var/www/xyz.org/includes/unicode.inc on line 478. 
Files with the '' extension are not allowed, please upload a file with a gif, jpg, png, bmp, eps, tif, psd, txt, rtf, odf, pdf, doc, docx, ppt, pptx, xls, xlsx, xml, avi, mov, mp3, or wav extension. 
warning: strrpos() expects parameter 1 to be string, array given in /var/www/xyz.org/sites/all/modules/webform_multifile/multifile.inc on line 491. 
warning: mb_substr() expects parameter 1 to be string, array given in /var/www/xyz.org/includes/unicode.inc on line 478. 
warning: strrpos() expects parameter 1 to be string, array given in /var/www/xyz.org/sites/all/modules/webform_multifile/multifile.inc on line 491. 
warning: mb_substr() expects parameter 1 to be string, array given in /var/www/xyz.org/includes/unicode.inc on line 478. 

It looks the same, except I guess it loops through the three files and puts out the warnings about the strrpos and mb_substr twice more. But I am supposing that's all fallout from the previous error. Once the uploaded file array gets figured out, the right info should be able to be plugged into these functions and resolve these errors.

When you want "screenshot of your webform structure" can you clarify what you mean? Do you want the list of form components or something? I can do that, but it's over 80 fields. Only about 10 are mandatory though. Or do you need something else?

Installed devel module, added dpm() call to multifile.inc. Running a test as a client user in IE8 with Compatiblity mode turned on, I still get the above warnings about strrpos and mb_substr and file extensions. What's new is that I now see this warning also:

warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/www/d6test/includes/bootstrap.inc on line 860. 

I don't see anything in orange like your screenshot but it dumps out what I expect is the $_POST array in a grey box, with this data:

Array
(
    [submitted] => Array
        (
            [pool_member] => City of Magellan
            [member_address] => 101 Main Street
            [liability_property] => 1
            [date_of_notice_to_fund_member] => Array
                (
                    [month] => 8
                    [day] => 8
                    [year] => 2012
                )

            [contract_number] => THX1138
            [coverage_effective_date] => Array
                (
                    [month] => 8
                    [day] => 1
                    [year] => 1979
                )

            [pool_member_contact_name] => Frank Urhft
            [pool_member_contact_number] => 512-444-4444
            [accident_date] => Array
                (
                    [month] => 8
                    [day] => 5
                    [year] => 2012
                )

            [accident_time] => Array
                (
                    [hour] => 
                    [minute] => 
                    [ampm] => am
                )

            [location_of_accident_or_loss] => Boardwalk
            [police_or_fire_investigation] => 0
            [description_of_accident_or_loss] => ferris wheel
            [describe_damage_to_pool_members_property] => car crushed
            [pool_members_vehicle_year_make] => 
            [model] => 
            [vehicle_identification_number] => 
            [license_plate_number] => 
            [insurance_company] => 
            [policy_number] => 
            [name_of_pool_members_driver] => 
            [age] => 
            [drivers_address] => 
            [drivers_home_phone] => 
            [drivers_title_or_position] => 
            [amount_of_estimate] => 
            [department] => Parks and Rec
            [department_head] => 
            [supervisor] => 
            [office_phone] => 
            [extension] => 
            [claimant_name] => 
            [claimant_address] => 
            [claimant_phone_number] => 
            [additional_claimant_name] => 
            [additional_claimant_address] => 
            [additional_claimant_phone_number] => 
            [claimant_vehicle_year_make_model] => 
            [company_or_agency_name__policy_number] => 
            [location_of_claimants_vehicle] => 
            [amount_of_claimant_estimate] => 
            [name_of_injured_1] => 
            [address_of_injured_1] => 
            [injured_1_phone_number] => 
            [extent_of_injury] => 
            [name_of_injured_2] => 
            [address_of_injured_2] => 
            [injured_2_phone_number] => 
            [extent_of_injury_2] => 
            [name_of_injured_3] => 
            [address_of_injured_3] => 
            [injured_3_phone_number] => 
            [extent_of_injury_3] => 
            [claimant_occupation] => 
            [claimant_employer] => 
            [name_of_witness] => 
            [witnes_address] => 
            [witness_phone_number] => 
            [additional_witness] => 
            [additional_witness_address] => 
            [additional_witness_phone_number] => 
            [member_special_requests] => 
            [multiple_attachments] => Array
                (
                    [_fids] => 
                    [_old_fids] => 
                )

        )

    [details] => Array
        (
            [sid] => 
            [page_num] => 1
            [page_count] => 1
            [finished] => 0
        )

    [form_build_id] => form-bf4bc7a1e96ecbcc1c6f07c0104d08fb
    [form_token] => addca714f123c0ab0953aaba4778c11c
    [form_id] => webform_client_form_413
    [op] => Submit
)

It still comes back to the form prepopulated with the file selection highlighted in red like it's a mandatory field. It now does this for IE8 in both Compatibility mode and normal mode, which is new. Previously, normal mode worked.

Will try the new multifile module dev version and update....

Attached is a screen shot of the result of a test as an admin using Chrome.

Hang on, I didn't realize it opened up further.

Some good news. I installed the latest dev version and submitting one or more files now works fine for IE8 in both normal and compatibility mode. I've tested it with admin and user accounts, and it's working fine.

However, if you are not adding any files, just submitting the form without attachments, it still errors out. In IE8, as a regular Member, it shows the warning about "Files with the '' extension are not allowed". The form is not accepted, but comes back with the data filled in and the file selector highlighted as if it's mandatory, but it's not. Snipped screenshot attached. The top section is the devel dmp output, though in IE, it seems not to play nice with the CSS and opening it up see all the levels messes up the appearance of the form.

I've noticed this also happens if you try editing a previous submission that may or may not have had files attached. Just resubmitting it without selecting at least one file yields this problem. And again this problem only happens using IE. And I would note that the field is NOT required in the webform component list.

Has anyone had a chance to follow up on this yet? Seems like it could be a simple fix to check if there are any values at all, but I'd rather not mess with it if it's a work in progress.

more detail