Jump to content

Topic on Project:Support desk

[SOLVED?] Problem With File Upload: Could not acquire lock for "mwstore://local-backend/local-public/1/1e".

26
Summary by Ciencia Al Poder

See Manual:Disabling file lock manager for the current solution if the problem is not with permissions, misconfigured paths or SELinux

66.183.40.23 (talkcontribs)

Hello,

For some reason when ever I try to upload files on my wiki it ends out with something like:

 -  Could not acquire lock for "mwstore://local-backend/local-public/1/1e".
 -  Could not acquire lock for "mwstore://local-backend/local-public/1/1e/Roadmap.png". 

Anyway, it seems to prevent upload and my wiki relies on file upload.

I've seen this problem before in the help desk but none really said anything I could follow.

I'm using MediaWiki 1.20.2.

PHP Version 5.3.3

MySQL 5.1.61

neonunknown.sourceforge.net

And of course it's urgent. :D


Thanks,

Hero

66.183.40.23 16:18, 18 December 2012 (UTC)

Ciencia Al Poder (talkcontribs)

See bugzilla:33294, although it shouldn't happen on 1.20

Where are files stored? On the physical drive with the wiki, a network storage...? The server has permissions to write and create files and folders on the image folder?

66.183.40.23 (talkcontribs)

Hello,

Yes it should have access. Though now and then I have an odd feeling about SF...

It think it's on disk.

Thanks,

Hero

66.183.40.23 (talkcontribs)

Hello,

Okay, I think it may be SF again. They're hosting is really weird. Thanks for helping.

Thanks,

Hero

Ciencia Al Poder (talkcontribs)
178.21.224.114 (talkcontribs)

Was an answer found for this issue?

128.210.67.100 (talkcontribs)

I am finding the same problem (except with f/f5 instead of 1/1e), on an installation without superuser access, i.e., the wiki is in a user directory exposed to the web server. Upon upload, under images/ it created three new directories: archive/f/f5/, f/f5/ and lockdir/. All are empty except for two zero-size files in lockdir/. The new directories are owned by the web server's user/group, and I had to chmod 777 the images/ directory to allow this, otherwise the server could not create anything because my user is not even in the same group.

If anyone knows how this is supposed to work, let us know.

Ciencia Al Poder (talkcontribs)

See my previous message. If it's not a permission issue, maybe the filesystem is missing some features required by the default lock manager (fsLockManager).

Try enabling the debug log and see if it gives more information about why it failed to acquire lock, or just switch the lock manager to the nullLockManager.

128.210.67.100 (talkcontribs)

Ok, I found a way to force nullLockManager, and my uploads work now. Change line 97 in includes/filebackend/FileBackendGroup.php from

                               'lockManager'    => 'fsLockManager',

to

                               'lockManager'    => 'nullLockManager',

A rather direct fix, in a way does not feel 'right'.

What is the preferred way of switching to nullLockManager, by the way? The list of lock managers in DefaultSettings.php is empty, it is populated in includes/Setup.php as far as I can tell, and if I comment out fsLockManager there I get "Internal error" later (since it is being referenced).

---

Discussion on SourceForge (sourceforge.net/p/forge/site-support/2758/) suggests the issue is with locking on NFS.

MarkAHershberger (talkcontribs)
Ciencia Al Poder (talkcontribs)

That page doesn't say anything useful.

I've made an example configuration for using to be able to specify a lockManager, based on what's posted on WPI/WindowsAzureStorage.

But anyway, having to specify all of this just to set the LockManager seems a bit overcomplicated.

Try this configuration and let us know if it works, to put it on the docs. Note that I haven't tested it:

// Create a local backend with a null lock manager
$wgFileBackends[] = array(
        'name'        => 'local-backend',
        'class'       => 'FSFileBackend',
        'lockManager' => 'nullLockManager',
        'containerPaths' => array(
                'local-public'  => "{$wgUploadDirectory}",
                'local-thumb'   => "{$wgUploadDirectory}/thumb",
                'local-transcoded' => "{$wgUploadDirectory}/transcoded",
                'local-deleted' => $wgDeletedDirectory,
                'local-temp'    => "{$wgUploadDirectory}/temp",
        ),
        'fileMode'    => 0644,
);

// Define a standard file repository that uses the local backend defined before
$wgLocalFileRepo = array (
        'class'             => 'LocalRepo',
        'name'              => 'local',
        'directory'         => $wgUploadDirectory,
        'scriptDirUrl'      => $wgScriptPath,
        'scriptExtension'   => $wgScriptExtension,
        'url'               => $wgUploadBaseUrl ? $wgUploadBaseUrl . $wgUploadPath : $wgUploadPath,
        'hashLevels'        => $wgHashedUploadDirectory ? 2 : 0,
        'thumbScriptUrl'    => $wgThumbnailScriptPath,
        'transformVia404'   => !$wgGenerateThumbnailOnParse,
        'deletedDir'        => $wgDeletedDirectory,
        'deletedHashLevels' => $wgHashedUploadDirectory ? 3 : 0,
        'backend'           => 'local-backend',
);
128.210.67.100 (talkcontribs)

Should these go to LocalSettings.php?

84.88.49.1 (talkcontribs)

I've done this and it lets you to upload files, but then I get the same error changing

FileBackendGroup.php from

                              'lockManager'    => 'fsLockManager',

to

                              'lockManager'    => 'nullLockManager',

The image is not visible in the wiki :-(

Ciencia Al Poder (talkcontribs)

You should not change the FileBackendGroup.php file if you apply the configuration change I suggested, supposing it solves the problem on upload.

If you have problems displaying images, be sure that configuration settings are placed at the bottom of LocalSettings, since you can see there that it uses other variables that should be already defined. If that does not work, you may try manually editing those settings replacing variables (those starting with "$") with the actual values it should contain.

84.88.49.1 (talkcontribs)

Thank you for answering.

I've corrected FileBackendGroup.php and modify LocalSettings.php as you said, and this is what I get just opening main page:

Notice: Undefined variable: directory in /w3/httpd/docs/mediawiki/LocalSettings.php on Notice: Undefined variable: deletedHashLevel in /w3/httpd/docs/mediawiki/LocalSettings.php on line 170

Warning: Cannot modify header information - headers already sent by (output started at /w3/httpd/docs/mediawiki/LocalSettings.php:152) in /w3/httpd/docs/mediawiki/includes/WebResponse.php on line 38

Warning: Cannot modify header information - headers already sent by (output started at /w3/httpd/docs/mediawiki/LocalSettings.php:152) in /w3/httpd/docs/mediawiki/includes/WebResponse.php on line 38

-(
Ciencia Al Poder (talkcontribs)

Uh, It seems that when I posted this:

'local-thumb'   => "{$directory}/thumb",

It should be this instead:

'local-thumb'   => "{$wgUploadDirectory}/thumb",

Basically, the error is that there's a variable named $directory in your LocalSettings.php at the specified line which is not defined. Change it by $wgUploadDirectory or replace it by a hardcoded value.

84.88.49.1 (talkcontribs)

Thank you, now I only have these errors:

Notice: Undefined variable: deletedHashLevel in /w3/httpd/docs/mediawiki/LocalSettings.php on line 170

Warning: Cannot modify header information - headers already sent by (output started at /w3/httpd/docs/mediawiki/LocalSettings.php:170) in /w3/httpd/docs/mediawiki/includes/WebResponse.php on line 38

Warning: Cannot modify header information - headers already sent by (output started at /w3/httpd/docs/mediawiki/LocalSettings.php:170) in /w3/httpd/docs/mediawiki/includes/WebResponse.php on line 38

Line 38 it's

public function header( $string, $replace = true, $http_response_code = null ) {

               header( $string, $replace, $http_response_code );
       }

I appreciate a lot your help :-)

Ciencia Al Poder (talkcontribs)

Ok, change the line

'deletedHashLevels' => $deletedHashLevel,

by

'deletedHashLevels' => 3,
84.88.49.1 (talkcontribs)

And If I try to upload:

Upload warning Could not create directory "mwstore://local-backend/local-public/2/21".

Warning: wfMkdirParents: failed to mkdir "/2/21" mode 0777 in /w3/httpd/docs/mediawiki/includes/GlobalFunctions.php on line 2546

line 2546-> trigger_error( sprintf( "%s: failed to mkdir \"%s\" mode 0%o", __FUNCTION__, $dir, $mode ),

                       E_USER_WARNING );
Ciencia Al Poder (talkcontribs)

It's trying to create a directory in the directory specified in the variable $wgUploadDirectory. Check what you set in that variable in LocalSettings and be sure it's writable by the webserver.

Try to change permissions recursively for that folder to 777. If that fixes the problem, then you can restrict it further, but be sure to make it owned by the user running the apache.

84.88.49.1 (talkcontribs)

Hello,

sorry for not answering since today :(

That directory it's OK (apache runs with nobody user).

 4 drwxrwxrwx 16 nobody nobody   4096 Mar  8 09:34 images

The problem I got without your modifications was 'could not acquire lock for...'. It created directories, but never let me to upload images, since I tried your solutions.

Ciencia Al Poder (talkcontribs)

Well, the changes I suggested was a still undocumented way to specify a null lock manager, because the filesystem you're using to store images doesn't allow locking files to prevent race conditions, something that MediaWiki is using by default.

The error message it's obfuscating the real directory which it's trying to create, under mwstore://local-backend/local-public/.... You could try to set a debug log file to see if it gives the exact directory it's trying to create and see if it's really the directory you're expecting to use. Maybe there's another configuration typo making it point to another directory.

2nd (talkcontribs)

Deleting files in /images/lockdir helped for me.

154.102.222.93 (talkcontribs)