search

snipe / snipe-it

A free open source IT asset/license management system
https://snipeitapp.com
GNU Affero General Public License v3.0
10.95k stars 3.16k forks source link

Import not working in V3 #2297

Closed pnelsonsr closed 6 years ago

pnelsonsr commented 8 years ago

Expected Behavior (or desired behavior if a feature request)

Being able to import a csv file

Actual Behavior

Rather than failing with an error, it's been just hanging indefinitely at the initial step of uploading the file (I'm not clear how to turn on debug mode)

image

Please confirm you have done the following before posting your bug report:

Please provide answers to these questions before posting your bug report:

pnelsonsr commented 8 years ago

OK we tried the command line import and that worked. So it looks like it might be the upload process stalling. BTW the output to the screen during the command line process is great! cd --snipeit install dir-- php artisan:import --path to csv file--

snipe commented 8 years ago

Can you check that your storage/private_uploads/imports/assets directory is writable?

dmeltzer commented 8 years ago

If this is a recent version of v3, there should be an error shown if the the directory isn't writable. I think.

pnelsonsr commented 8 years ago

I checked the dir storage/private_uploads/imports/assets and it was (and the whole path) was 755 and owned by apache. Within that directory I found said upload files (set to 644) and also owned by apache. So it looks to be writing to the directory just fine. I did check the the files were really cvs files and they were.

pnelsonsr commented 8 years ago

OK actually the files were the old files I mentioned as we had previously imported.

snipe commented 8 years ago

So what's the status of this?

pnelsonsr commented 8 years ago

We were able to do the import through the command line but not through the web interface. I checked that the dirs have the proper permissions. So I'm not sure what the problem is. However we can do it through the CMI so we are ok.

skleinau commented 8 years ago

Hello,

we are experiencing a similar issue. Uploading files through UI does not work (bar fills 100% and stays like this) without finding something in the logs of SnipeIT or Nginx.

Folders are there and accessible. If we upload manually to this folder it is shown in UI and cmd processing of imports is working as well.

Therefore only the upload is not working and the browser gives the following:

views exception

Thanks Stefan

dmeltzer commented 8 years ago

Can you check the javascript console? It's usually in the developer tools menu of your browser.

skleinau commented 8 years ago

Hello,

I checked in Chrome and Firefox but the Console stays empty (JS Errors and Warnings to be logged).

Otherwise I would have posted it here, or do you mean something else?

Thanks Stefan

pnelsonsr commented 8 years ago

We never got it working through the browser.

snipe commented 8 years ago

The only reason that upload should fail is if the directory (storage/private_uploads/imports/assets) isn't writable.

pnelsonsr commented 8 years ago

we made it part of our process to do it on the Command Line which I'm totally comfortable with anyways. My dir has the correct ownership and permissions so I don't know what else it could be.

skleinau commented 8 years ago

Hello,

@pnelsonsr thanks for the feedbacks.

@snipe I can definitely say that our folders are owned by the web server user and can be written by him as after copying the file into the folder, we use the UI to process the import and the .txt files generated during this process are stored there properly.

Thanks Stefan

bleslie27 commented 8 years ago

Similar issue experienced on our end. Using the UI to import now hangs at 0%. Previously, (evening before) , I was able to import the same or similar files csv files , however, now all files hang. I cleared out the assets folder and cycled both docker containers (snipeit and mysql), however, same result. Are there any other file locations/storage, etc that can be cleared out try and push forward? using v3.4

ebonweaver commented 7 years ago

Confirming we also have the originally reported and later confirmed issue. You can not upload a CSV via the web UI, it never goes past 0%. This is using the example csv from the documentation site. No idea where there are any sort of error logs with this software that may explain why this is failing, happy to look if there is such a thing. This is with v3.3 but I see above 3.4 also reported. Seems this is a persistent issue? Has it been fixed in a new release with no update to this thread? I'd update and try but I've been searching for a couple weeks how to actually update the software when it was installed with the install.sh method and no one seems to know...

snipe commented 7 years ago

No idea where there are any sort of error logs with this software that may explain why this is failing

https://snipe-it.readme.io/docs/getting-help#step-3-check-your-app-and-server-logs

Seems this is a persistent issue? Has it been fixed in a new release with no update to this thread?

When the upload never gets past 0%, it's almost always a permissions error on your end, not a software issue on ours.

ebonweaver commented 7 years ago

Thanks for that info. There seems to be some points of deficiency here. There is nothing in the log file, so whatever is going wrong is failing to generate an error (or fail out at all given it sits at 0% indefinitely). That would seem to be a behavior that could be improved. Because there is no error, there is nothing to go on to fix this problem. Also worth noting that app_debug is set true and still no errors are generated.

Given this instance was created with the install.sh as mentioned, if there is a permissions problem that would indicate a deficiency in the installer. Other web products I've used do a health check that would check among other things permissions and show you the things that are in need of action. Is there a function like this with Snipe that I've overlooked?

As others have stated in response to mention of the assets directory permissions previously, the permissions are set as expected, which is the webserver (www-data) has write access. If there is some other permission issue, again we have no way to tell what it is due to lack of error/log on the issue. I set the directory to rwx for all and still no luck, permissions don't get much wider than that. Any advice is appreciated.

Oddly, the assets directory had a great number of csv and txt files in it, but most were 0 bytes in size. Again most, not all, so it's still unclear why some files would be uploading and others not, even just minutes apart. And, if some did upload ok, why did it still stick at 0% and not import anything? I deleted all the files and tried another import. Still sticks at 0%, and now nothing is being written at all, not even 0 bytes. Still nothing in the laravel.log either (other than authentication notes).

With respect, this very much seems like a software issue so far. While somewhat off topic, I'm also more than happy to update to 3.6 to see if that changes anything if you can provide some guidance how to do that. Thanks!

snipe commented 7 years ago

What about browser errors? That's an Ajax uploader, so if your APP_URL is not exactly the same as the URL you use to get to the app, the Ajax won't fire correctly.

ebonweaver commented 7 years ago

AH HA! So there is either a flaw somewhere, or a note missing, or I just plain goofed because I didn't know there was another setting... Any way you slice it, it would be great if the software would check for this issue and/ or report the failure better. The problem was the site is set up for https. The app_url in the .env file was set to http://. This caused the upload to be silently blocked due to mixed active content issues in the security of the site. As soon as I changed the .env to https it uploads fine. Important safety tip!

It's also worth noting (admittedly for those gunshy about clicking buttons or looking around) that the import does not actually import, it only uploads. You then have to click the process button next to the uploaded file in the import screen. I'd offer a couple thoughts on this:

  1. The button for "Select Import File" should maybe say "Upload".
  2. The button for "Process" should maybe say "Import"
  3. Once a file has been imported, perhaps it should be deleted automatically, or if not a "Delete" button should be added next to the Import button for the file. I think these things would make the UI more clear, and the clean up is probably important. Although importing (process) the file a second time doesn't seem to be an issue, this upload screen could become cluttered in some settings. If this was being left as a type of log, perhaps logging to a real import log would be better?

Thanks for the assist, hope this helps others/ is useful feedback :)

snipe commented 7 years ago

We make it pretty clear in the documentation that those urls must match exactly, and if they don't, we try to warn you in the preflight setup. I'' not really sure what else you want us to do. It's well documented already.

ebonweaver commented 7 years ago

Regarding the variable itself, again I'm not sure what went wrong as I don't recall the exact sequence of install and setup 3 months ago when I started playing with this product.

If it was set up with SSL from the start as part of your install.sh script in the choices I was offered, then there is a defect because this critical variable was not set to https.

If I changed the site .conf file to use ssl myself, then the problem is I had no way of knowing this was an issue without reading through documentation I wasn't aware of to find a setting I didn't know was important. Absolutely every other thing in the software works fine other than the upload, and there is nothing overt indicating the issue. In all my years I have never seen another product that works like this where there is another internal pointer in its own config, everything else I ever worked with works at the webserver config level to find itself.

So, what I'm suggesting, despite possibly being a niche case, is because of how this product works putting in a quick bit of code that would detect this mismatch when you try to do an upload and display an error rather than just sitting at a 0% bar. I don't know if this is what affected others in this thread or not as they haven't chimed in with their issue or solutions, but I think this would be a helpful enhancement to facilitate self troubleshooting in the product. As is, while documented, I never saw that as I wasn't doing a manual install I relied on your script, and there was no error in the UI or logs, so it's a mystery with no clues to start with. If it has said "upload failed, connection is https but environment is set to http" or something like that, there would have been a clear indication why it wasn't working.

As for the follow up suggestions on the UI once it's working, I know they are OT but hopefully helpful. If you want me to log them as formal suggestions in another way I'm happy to do so, just point me to the best place. If you don't see any of it as significant, I gave my $0.02 for what it's worth :)

paulhite commented 7 years ago

I'll resurrect this thread for a minute just to say that we also ran in to this - used a vanilla CentOS 7 installation and then ran install.sh. Later that week I used certbot to generate SSL cert automatically and import broke. While it was obvious for us what broke it, I can imagine if someone had swapped to SSL during the initial flurry of setup and then didn't try importing anything for a few days might be scratching their head.

The app, install script, and docs are all beautiful, and I'm not here to shame those, but there is certainly a scenario where someone who used install.sh to generate the base .env file didn't read the whole manual (/raisehand) might get stuck unaware there is a URL discrepancy.

firmank commented 6 years ago

hi snipe, i have similar case, the upload process status was "success!", but import process heven't finish yet until now (already took more than 5 hours), data only 159 KB, i have checked Asset Tag is unique, i checked the folder C:\wamp\www\snipe-it\storage\private_uploads\imports confirmed not readonly.