Is the apache user in the eprints group?

We found that for fewest errors, the apache user and the eprints user need to be in each other’s groups.

Lizz

Hmm, I thought it might have been a permissions issue. I checked the folders and saw that the new ones being created under disk0 were being set to user www-data. I checked in the envvars and apache was running as www-data. Changed it to eprints, restarted apache but still nothing. It’s not even creating new folders under disk0. Chowned all the existing folders to eprints:eprints, perms are drwxrwsr-x. Checked the error log and I’m not seeing anything in there. It’s odd, I’m not sure where to look next.

Things to investigate:

                ls -l <eprints_root>

                ls -l <eprints_root>/archives/<archive_id>/documents

                ls -l <eprints_root>/archives/<archive_id>/documents/<path for the eprint id you’re failing to upload to>

                Check user, group and permissions

                Next, check what user the apache process is running as.  This is in the apache configuration file.  Its location varies depending on what distribution it’s in.  Compare that user to the user in the permissions above.

                Next, use:

                                df -h

                …to check that you have adequate disk space (it’s almost certainly not that -- you’d have other issues if it were).

                Actually, before you even to that, it’s probably a good bet to check the apache error log to see if you can get any clues there.  If apache is complaining at you, it’s probably an issue with the server.  Again, the location of the error log varies by server, but it’s a default anyway and may be overridden by the config.  Check your apache configuration to see where the error log is being stored.  It might be /var/log/apach/error.log -- you’ll probably need to be root to see it.  The ‘tail -f <error_log_full_path>’ command is your friend.  It’ll show you the most recent entries in the log, and then display them as they come in.  Run that command and then try to upload a file, see what the error it.  It’s likely to be lots of lines.  You sorta need to read all of them to see if you can find the critical line that gives you the clue -- it’s likely to be the first or second line, but it might be buried.  Note that a problem like this causes knock-on issues, so there may be lots of sifting to do.

--

Adam

Any thoughts on this as well? I’ve tested it again and I’m not getting an error through file upload however if I try to add a file from URL I’m getting a “document creation failed” error. I’m not sure if it’s a permissions issue or a server issue (firewall etc)

Andrew

Hello all,

Another problematic one – I can’t seem to upload files to my new repository. On doing an upload it briefly brings up the progress bar which then promptly vanishes. For info, I’m trying to upload a “test.pdf” file which is fairly small, only containing the word test, that I have in reserve for this kind of occasion. I’ve checked folder permissions and they’re all eprints:eprints, and as I’m not getting an error I’m not sure where the problem may lie. The only thing I can think of is that I notice the EPrint ID index has started at 1 after importing my EPrints (via a direct database import) so I’m not sure if there’s a way to start indexing after the most recent EPrint ID? The document problem seems to be some kind of permissions thing to me, though.

Andrew

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech *** Archive: http://www.eprints.org/tech.php/ *** EPrints community wiki: http://wiki.eprints.org/ *** EPrints developers Forum: http://forum.eprints.org/