-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic backups working but manual backups failing #7172
Comments
I'm actually seeing the same error, also using Ubuntu 18.04.2 LTS and have done the same troubleshooting steps as you describe. This is a new install just completed last week, weekly backup ran fine, I wanted to run a manual one today after adding a number of assets and custom fields. Got the same error you are describing, everything else seems to be functioning correctly. My system did send me the following error block which I will add here in case it helps hunt down where the difficulty with manual backups is located:
|
I have similar issue. |
I have confirmed this as an issue and can see that the automated backups that are created in the back end on a CentOS 7 container are owned by root, whereas the snipeit user is what I think is trying to generate the backups from the manual backup process. I checked my directory: /var/www/html/snipeit/storage/app/backups In my case, we snapshot the entire container after major changes, so it isn't as big a deal that the manual backup isn't working. |
I can confirm this on CentOs as well. if I chmod the entire storage folder to 777, the backups work, on my machine they're being created by apache and not even by the snipeit user
You'll note the folder itself has group access for apache, but even then if I do 755, it still fails, I've even tried 766 and 776, this literally causes the backup page to go "whoops, something went wrong" so obviously there's something that requires execute that is not clearly documented.
I even tried adding mysql to snipeit on the incredibly off chance it was something that sql needed to do. |
That looks more like a linux permissions issue than anything else. If you run something via the web GUI, its always going to run as whatever user your web server runs as, versus when you run it via cli, it runs as whatever user you're logged in as. Without details on your "Whoops", I don't have a way to troubleshoot that, but I'm 99% certain it's a group/owner/permissions issue. If you look at your app log, I'd bet you'll see a permissions error. |
Question, the error I see is failed to create directory, where is it trying to create a directory that in a 775 folder it's not able to do so? When it's done there are no directories added to backups that I recall seeing. |
I believe that backup system creates a tmp directory (that it then deletes), so the storage directory and everything in it needs to be writable. |
Coming back to this issue very late, but was talking to some others in a sysadmin Slack channel and found the fix. Did some digging and found at some point in time permissions had gotten twisted around and some files within the ./storage directory were chowned to another user, maybe during an upgrade? Regardless, ran:
Then just ran the typical |
If that's not a huge reminder to not just copy/paste commands without looking. If you Basically the above just changed ownership to user/group www-data and then immediately changed it over to the USER 755. Completely removed access to everything. Website was showing zero assets/users/etc. until I ran a ls -l and was like "hey since when does user/group 755 own stuff" |
Oh boy, thanks for catching that. Apologies for the mistype. I've corrected it in my above comment so no one else gets tripped up. |
No problem! I just wish I would have noticed it before I copy/pasted into Putty lol |
Please confirm you have done the following before posting your bug report:
Describe the bug
Automatic weekly backups are being generated perfectly fine, but attempting to manually generate a backup fails and results in an error message of:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Expect that a backup is generated when manually clicking the "Generate Backup" button.
Screenshots
Backup Page Error Screenshot
Server (please complete the following information):
Desktop (please complete the following information):
Error Messages
storage/logs
and your webserver's logs: no error being written to /storage/logsAdditional context
Add any other context about the problem here:
I try to keep SnipeIT updated to the latest version, and this issue started appearing within the last couple updates of SnipeIT. Haven't attempted to run a manual backup in about a month and noticed this when trying to do so today. I've tried the usual fixes of running the artisan config:clear and similar commands, but no luck there. I've tried deleting the vendor directory and reinstalling composer, but that didn't work either. I've checked the settings within the .env file and verified that the credentials it's using to log into the MySQL database are fine, and they are. The tables it's pulling from appear to be all correct as well, and nothing's ever been manually modified within the database.
It looks like this may be related to a permissions issue of some sort. When checking the backup timestamps, it looks like the auto-generated backups are being created as root, yet manual backups are being created under the user snipeitapp that was created for use with SnipeIT. See screenshot below:
Terminal output screenshot
Not quite sure why this is an issue though as the storage, app, and backups directory are all owned by user snipeitapp and have 775 permissions. And again, this process worked fine about a month or so ago and before that point. Possibly something was changed on the update released around June 2nd as it looks like the backup file naming convention changed as well. I'm pretty sure the permissions are the issue here and I'm sure it's something fairly obvious that I'm missing, but just can't connect the final dots. Thanks in advance for any help.
The text was updated successfully, but these errors were encountered: