Snipe-it: Issue backing up from web interface

[MSTigers]

Expected Behavior (or desired behavior if a feature request)

To have a backup file saved when I click the green "Generate Backup" button on the /admin/backups page.

---

Actual Behavior

Get the message " Success: A new backup file was successfully created." but nothing is listed under the Backups page. When I navigate to /var/www/snipeit/storage/app/backups there is only one file (.zip) that was backed up 10 days ago, and a env-backups directory that is empty. None of the expected 'new' backups.

---

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

• [Y] I have enabled debug mode
• [Y] I have read checked the Common Issues page

---

Provide answers to these questions:

• Is this a fresh install or an upgrade?
  Pretty much a fresh install
• Version of Snipe-IT you're running
  Version v4.1.0 build beta2
• Version of PHP you're running
  PHP 7.0.22-0ubuntu0.16.04.1
• Version of MySQL/MariaDB you're running
  mysql Ver 15.1 Distrib 10.1.28-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
• What OS and web server you're running Snipe-IT on
  Ubuntu Server 16.04.1 Server version: Apache/2.4.18 (Ubuntu)
• What method you used to install Snipe-IT (install.sh, manual installation, docker, etc)
  install.sh
• WITH DEBUG TURNED ON, if you're getting an error in your browser, include that error
  No errors.
• What specific Snipe-IT page you're on, and what specific element you're interacting with to trigger the error
  /admin/backups page, clicking the green Generate Backup button.
• If a stacktrace is provided in the error, include that too.

[2017-11-15 14:00:56] production.ERROR: ErrorException: ldap_search(): Search: Bad search filter in /var/www/snipeit/app/Models/Ldap.php:262
Stack trace:
#0 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'ldap_search(): ...', '/var/www/snipei...', 262, Array)
#1 /var/www/snipeit/app/Models/Ldap.php(262): ldap_search(Resource id #176, 'dc=tigernet,dc=...', '((&(objectCateg...')
#2 /var/www/snipeit/app/Console/Commands/LdapSync.php(70): App\Models\Ldap::findLdapUsers()
#3 [internal function]: App\Console\Commands\LdapSync->handle()
#4 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(29): call_user_func_array(Array, Array)
#5 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(87): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}()
#6 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(31): Illuminate\Container\BoundMethod::callBoundMethod(Object(Illuminate\Foundation\Application), Array, Object(Closure))
#7 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Container/Container.php(539): Illuminate\Container\BoundMethod::call(Object(Illuminate\Foundation\Application), Array, Array, NULL)
#8 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Console/Command.php(182): Illuminate\Container\Container->call(Array)
#9 /var/www/snipeit/vendor/symfony/console/Command/Command.php(262): Illuminate\Console\Command->execute(Object(Symfony\Component\Console\Input\ArrayInput), Object(Illuminate\Console\OutputStyle))
#10 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Console/Command.php(167): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArrayInput), Object(Illuminate\Console\OutputStyle))
#11 /var/www/snipeit/vendor/symfony/console/Application.php(888): Illuminate\Console\Command->run(Object(Symfony\Component\Console\Input\ArrayInput), Object(Symfony\Component\Console\Output\BufferedOutput))
#12 /var/www/snipeit/vendor/symfony/console/Application.php(224): Symfony\Component\Console\Application->doRunCommand(Object(App\Console\Commands\LdapSync), Object(Symfony\Component\Console\Input\ArrayInput), Object(Symfony\Component\Console\Output\BufferedOutput))
#13 /var/www/snipeit/vendor/symfony/console/Application.php(125): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArrayInput), Object(Symfony\Component\Console\Output\BufferedOutput))
#14 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Console/Application.php(141): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArrayInput), Object(Symfony\Component\Console\Output\BufferedOutput))
#15 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(220): Illuminate\Console\Application->call('snipeit:ldap-sy...', Object(Illuminate\Support\Collection), NULL)
#16 /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(221): Illuminate\Foundation\Console\Kernel->call('snipeit:ldap-sy...', Array)
#17 /var/www/snipeit/app/Http/Controllers/UsersController.php(1031): Illuminate\Support\Facades\Facade::__callStatic('call', Array)
#18 [internal function]: App\Http\Controllers\UsersController->postLDAP(Object(Illuminate\Http\Request))
@

• Any errors that appear in your browser's error console.
  n/a
• Confirm whether the error is reproduceable on the demo: https://snipeitapp.com/demo.
  n/a (DEMO MODE: Some features are disabled for this installation.)
• Include any additional information you can find in app/storage/logs and your webserver's logs.
  n/a

• Include what you've done so far in the installation, and if you got any error messages along the way.
  Confirmed that .env is DB_DUMP_PATH='/usr/bin' /usr/bin has all the mysql dumps and files in there.

• Indicate whether or not you've manually edited any data directly in the database
  I have edited some items, such as Database Settings (user, password, etc.) and smtp settings. Nothing edited to my knowledge that would effect the problem at hand.

Please do not post an issue without answering the related questions above. If you have opened a different issue and already answered these questions, answer them again, once for every ticket. It will be next to impossible for us to help you.

https://snipe-it.readme.io/docs/getting-help

[MSTigers]

Taken at the time of this comment (2017-11-15). You can see the only backup recorded. I didn't manually make that 2017-11-05 backup, I don't think anyways. Most likely generated it after we got it setup.

contents of /var/www/snipeit/storage/app/backups

.env Database configuration

Contents of my /usr/bin directory for DB_DUMP_PATH='/usr/bin'

[snipe]

Is your backup directory writable? Without specific errors, I don't really have any way of knowing why it failed. You can try upgrading, as we've added slightly more verbose feedback if a backup failed in later versions.

[MSTigers]

username@stuff:/var/www/snipeit/storage/app$ drwxr-xr-x 3 www-data www-data 4096 Nov 4 19:00 backups

[MSTigers]

username@stuff:/var/www/snipeit/storage/app/backups$ ls -l
total 40
-rw-r--r-- 1 root root 35378 Nov 4 19:00 2017-11-05-000001.zip
drwxr-xr-x 2 www-data www-data 4096 Nov 1 08:17 env-backups
username@stuff:/var/www/snipeit/storage/app/backups$

The zip that's there from before is from root, not sure if that's relevant or not but noticed the difference between that and the env backup directory.

[MSTigers]

A lot of the other content I was going through, people had their mysql dumps pointed at /usr/local/bin. But I don't think that should matter, especially considering it looks like mine dumps into the /usr/bin.

Do you see any syntax issues that I am missing that could be telling Snipe a different location? e.g., /usr/bin vs. /usr/bin/

I can try an upgrade as well if you would think it can help. We've not fully used it yet, I was just trying to get a backup going at this 'fresh start' point before I accidentally break it in the near future getting it setup. We got a new shipment of 100+ Chromebooks we're going to put in to get the kinks worked out before we move our entire inventory into it.

[snipe]

We use DB_DUMP_PATH='/usr/local/bin', no trailing slash.

[MSTigers]

OK that's what I thought and what I have. I was hoping it would be something embarrassingly easy. One thing I noticed is that in my .env the APP_URL did not match the actual current IP address. When I initially set it up I was in a different physical location from where I am now finishing the setup.

I corrected it in the .env APP_URL and ran the php artisan config:clear, but the problem still persists.

[snipe]

APP_URL isn't used by the backup script (it wouldn't, since backups would relate to the path, not the URL). It's still super important to have that APP_URL correct, as all kinds of other stuff will break (javascript, ajax menus, etc) because of Cross-Domain browser restrictions, but it's not related to this.

Try running php artisan snipeit:backup -vvv from the cli, and tell me what the output is.

[snipe]

(The web UI simply invokes that artisan command, so running it via cli is the same as hitting the "backup" button)

[MSTigers]

username@stuff:/var/www/snipeit$ php artisan snipeit:backup -vvv
Starting backup...
Dumping database snipeit...
Backup failed because The dump process failed with exitcode 2 : Misuse of shell builtins : sh: 1: cannot create /var/www/snipeit/storage/laravel-backups/temp//snipeit.sql: Directory nonexistent
.
Backup failed because: The stream or file "/var/www/snipeit/storage/logs/laravel-2017-11-15.log" could not be opened: failed to open stream: Permission denied.

[UnexpectedValueException]
The stream or file "/var/www/snipeit/storage/logs/laravel-2017-11-15.log" could not be opened: failed to open stream: Permission denied

[snipe]

Is /var/www/snipeit/storage/logs writable?

[MSTigers]

drwxr-xr-x 2 www-data www-data 4096 Nov 15 08:00 logs

[snipe]

Okay, related to https://github.com/spatie/laravel-backup/issues/92#issuecomment-200327709 - possibly a permissions issue re: mysqldump?

[snipe]

(That's the library we use for backups - snipeit:backup is just a think wrapper over it)

[MSTigers]

Updated the comment above (you were too fast!) with a picture. Is the fact that root the owner of laravel-backups related? Also thank you for reference, looking through it now.

[snipe]

Well, it looks like www-data is the owner of the backups dir.

username@stuff:/var/www/snipeit/storage/app$ drwxr-xr-x 3 www-data www-data 4096 Nov 4 19:00 backups

What I'm wondering about is if your user has permission to use mysqldump, or if maybe that storage/app/backups dir needs additional permissions.

Are you running SELinux by any chance?

[MSTigers]

I don't believe I am. ( http://www.microhowto.info/howto/determine_whether_selinux_is_enabled.html ) getenforce prompted me to run sudo apt install selinux-utlis. I'm not very familiar with it, so had to Google how to check if you are using SELinux.

As for my note on the laravel-backup and root, the error thrown "Directory nonexistent" during the php artisan snipeit:backup -vvv had me curious. Looking into your other questions now.

[snipe]

We also tell you how to check for SELinux in our docs.

[MSTigers]

What I'm wondering about is if your user has permission to use mysqldump, or if maybe that storage/app/backups dir needs additional permissions.

Which user would it be that you're referring to? www-data, mysql? A different one?

Also here's the current permissions for everything in the /usr/bin for mysql. Not sure if that's of any help.

[snipe]

drwxr-xr-x 2 www-data www-data 4096 Nov 15 08:00 logs

It's still saying it can't create that log file though, which is odd. In your .env, add or update APP_LOG=single and clear the config cache. Sometimes issues with logging can cause unpredictable other weirdness that causes red herrings, so I at least want your logs to be working.

[snipe]

Which user would it be that you're referring to? www-data,

Whichever one you're logged in as when you run the cli backup tool.

[MSTigers]

It's still saying it can't create that log file though, which is odd. In your .env, add or update APP_LOG=single and clear the config cache. Sometimes issues with logging can cause unpredictable other weirdness that causes red herrings, so I at least want your logs to be working.

All right, APP_LOG=single added under BASIC APP SETTINGS section. Config cache cleared. Do you need me to check anything now?

Whichever one you're logged in as when you run the cli backup tool.

My username is currently a member of the following groups: adm cdrom sudo dip www-data plugdev lxd lpadmin sambashare

I'm not very good with Linux, especially permissions so I apologize in advance. If there's anything that is outside of the scope of "your problem" let me know and I will try to resolve it on my end and get back to you. I appreciate your help thus far!

[snipe]

Heh, this is all kinda outside the scope of a Snipe-IT problem, but I'd still rather take some time and get you set up correctly.

Now that you've changed to a single log file format, try running that cli backup again and see if the errors are any different.

I feel like we've narrowed this down to a permissions issue, either on the backup directory or on mysqldump, but let's see what happens when you run that cli backup again.

[MSTigers]

Pretty much the same, minus naming scheme of the log.

[MSTigers]

(The web UI simply invokes that artisan command, so running it via cli is the same as hitting the "backup" button)

When I use the web UI (clicky button) to run it, what user account is Snipe-IT using to attempt to run artisan command?

I could make a new group or utilize an existing one to chown of the mysql files in /usr/bin - so long as I make sure whatever else needs it can still use it.

[snipe]

When I use the web UI (clicky button) to run it, what user account is Snipe-IT using to attempt to run artisan command?

It's going to run it as whatever user apache (or whatever web server you're using) runs as, which in your case I hope is www-data, since that's who owns all the files. Running it via command line will run it as whatever your logged in cli user is - so it's not a perfect test by any means, but it at least can give us a little more info.

It could be that your currently logged in cli user isn't part of the www-data group and that's why it can't create those directories via cli - which in general isn't awful, but could definitely make some of the command line tools Snipe-IT has built-in a little more challenging.

Let's try this: chmod your storage directory (and all subdirs) to 777. We won't keep it that way forever but let's just see if we get a different error.

chmod -R 777 storage from your snipe-it project root.

Then re-run your cli backup.

[MSTigers]

-.-

[snipe]

Well well well....

So it definitely looks like a permissions/group issue.

[MSTigers]

The great green clicky button on the web UI also works, logs are now correctly populating the /admin/backs webpage.

[snipe]

Okay let's try dropping it down to 775 then. chmod -R 775 storage and re-test.

[snipe]

(I basically want to give it the smaller permissions allowable for it to still work)

[MSTigers]

Fails. But only one line this time.

Backup failed because The dump process failed with exitcode 2 : Misuse of shell builtins : sh: 1: cannot create /var/www/snipeit/storage/laravel-backups/temp//snipeit.sql: Directory nonexistent

[snipe]

Okay - there's probably some finessing you can do with regard to users/groups permissions to try to prevent having to grant 777, but at least it works now at 777. (Switch it back to 777.)

I'm going to close this ticket for now. Feel free to open a new one if you have additional issues.

[santacruzlp]

Hello!
As for the error Issue backing up from web interface # 4458, for me the solution was to run this command below as root, inside the / var / www / snipeit /

php artisan snipeit: backup

After that the button of the web interface returned to work well.

[pfenning-IT-OPs]

In our case the snipeit\storage\app\backup folder did not have 775 permission.