1592279 - NS_ERROR_STORAGE_IOERR on ubuntu 16.04 with cifs

Status: UNCONFIRMED

(Toolkit :: Storage, defect, P5)

Description

[Machiel]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Log in on a Ubuntu 16.04 desktop with the home directory on a cifs network share.

Attempt to open a OnlyOffice sample document with the Web Console opened.

Test server: http://178.32.249.86:81/onlyoffice_php/ (not my server)

Actual results:

The document does not load the error NS_ERROR_STORAGE_IOERR is displayed in the webconsole.

This same error appears on other sites but this one is easiest to reproduce.

Expected results:

The sample document should load.

Comment 1

[Machiel]

Attachment: firefox-storage-test_2019-10-30_09-24-03.png

Results from firefox-storage-test.glitch.me

Comment 2

[Machiel]

The dom.storage.next_gen is set to false, resetting the profile does not resolve the issue.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

I'm moving this temporarily to the Toolkit :: Storage component which is where our SQLite wrapper, mozStorage, lives and this sounds like it could be a problem with SQLite being unhappy on the CIFS remote filesystem. The IO error is a little surprising.

I think the best first step would be if you could run Firefox with our MOZ_LOG mechanism enabled for mozStorage at its maximum level so that we can see what's triggering the I/O error. Our general documentation is under "Enabling Logging" at https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Gecko_Logging.

What you would do is set the environment variable MOZ_LOG to "timestamp,mozStorage:5". MOZ_LOG_FILE can be used to direct the logs to a file. If omitted, the logs go to stderr.

So two example ways to run:

MOZ_LOG=timestamp,mozStorage:5 firefox -P SOMEPROFILE &> LOGFILE

MOZ_LOG=timestamp,mozStorage:5 MOZ_LOG_FILE=LOGFILE firefox -P SOMEPROFILE &> LOGFILE

If used on a fresh profile, there shouldn't be any personally identifying information other than file paths, but you should feel free to email the log files to directly to [e-mail] and [e-mail] and [e-mail] if you're not comfortable attaching them to this bug.

Thank you for your assistance in this!

Comment 4

[Machiel]

Attachment: ff_1592279_2019-10-30.log.tgz

Comment 5

[Machiel]

I've attached the log, this is a test user with a clean profile and cache doing the firefox-storage-test.glitch.me test.

Comment 6

[Jan Varga [:janv]]

So results for firefox-storage-test.glitch.me are the same (all broken) with a clean profile ?

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Hm, at first glance, the mozStorage logs aren't doing a good job of indicating when sqlite3_step results in a notable error. Bug 531122 is our stalled bug on enhancing our MOZ_LOGs, noting that I don't think the bit-rotted patch there directly covers adding the result value.

Comment 8

[Tom Tung [:tt, :ttung]]

I checked the log and it seems that you visited http://firefox-storage-test.glitch.me rather than https://firefox-storage-test.glitch.me (should be "https"). Could you rerun the website and share the result? Thanks!

Comment 9

[Tom Tung [:tt, :ttung]]

(In reply to Tom Tung [:tt, :ttung] from comment #8)

I checked the log and it seems that you visited http://firefox-storage-test.glitch.me rather than https://firefox-storage-test.glitch.me (should be "https"). Could you rerun the website and share the result? Thanks!

Hmm, never mind. I might be wrong because I also found https://firefox-storage-test.glitch.me in the log. And even if you ran "http", the result shouldn't look like that.

Comment 10

[Machiel]

(In reply to Jan Varga [:janv] from comment #6)

So results for firefox-storage-test.glitch.me are the same (all broken) with a clean profile ?

Yes they are, although the LocalStorage test can return Good after a first run, the others always return the same error.

I have also purged and reinstalled FF to be sure, and removed ~/.mozilla & ~/.cache before testing.

Comment 11

[info]

I got the exact same error.

Storage doesn't work with http sites.

I can confirm this when visiting "http://firefox-storage-test.glitch.me/"

Output:

LocalStorage
Bad: Our test logic is broken, please copy and paste the contents of 'Debug Info' below and anything in the devtools console and send to :asuth. (unexpectedBreakage)
QuotaManager
Bad: Totally Broken. (fullyBroken)
IndexedDB
Good: Totally Working. (fullyOperational)
Cache API
Bad: Totally Broken. (fullyBroken)

Debug Info:

navigator.storage not available in this build, inferring status.
The operation is insecure.

{
"v": 1,
"curVersion": 70,
"prevVersion": 0,
"ls": {},
"qm": {
"lastWorkedIn": 0
},
"idb": {
"persistentCreatedIn": 0,
"persistentLastOpenedIn": 70,
"clearDetectedIn": 0
},
"cache": {
"firstCacheCreatedIn": 0,
"unpaddedOpaqueCreatedIn": 0,
"paddedOpaqueCreatedIn": 0
}
}

When visiting the site with https:

LocalStorage
Bad: Our test logic is broken, please copy and paste the contents of 'Debug Info' below and anything in the devtools console and send to :asuth. (unexpectedBreakage)
QuotaManager
Good: Totally Working. (fullyOperational)
IndexedDB
Good: Totally Working. (fullyOperational)
Cache API
Good: Totally Working. (fullyOperational)

Debug Info:

{
"v": 1,
"curVersion": 70,
"prevVersion": 0,
"ls": {},
"qm": {
"lastWorkedIn": 70
},
"idb": {
"persistentCreatedIn": 0,
"persistentLastOpenedIn": 70,
"clearDetectedIn": 0
},
"cache": {
"firstCacheCreatedIn": 0,
"unpaddedOpaqueCreatedIn": 0,
"paddedOpaqueCreatedIn": 70
}
}

Firefox 70.0.1 (64-bit) on Ubuntu 18.04

Comment 12

[Machiel]

Results are still the same for us on 16.04 in FF 70.0.1 http & https.

On 18.04 I have the same as above, never noticed this difference, I had only tested https. Both have their profiles on cifs.