Skip to content
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

Backup permission issue: Could not change directory #2508

Open
antondollmaier opened this issue Mar 7, 2019 · 11 comments

Comments

@antondollmaier
Copy link

commented Mar 7, 2019

Infos:

  • Used Zammad version: 2.9.0-1551759158.fdc9ddac.stretch
  • Installation method (source, package, ..): deb
  • Operating system: Debian Stretch
  • Database + version: Postgresql 9.6
  • Elasticsearch version: 5.6.15
  • Browser + version: not relevant

Expected behavior:

  • when running zammad_backup.sh as root as a cronjob, no errors should be shown.

Actual behavior:

  • Cronjob:
    30 3 * * *  root  /opt/zammad/contrib/backup/zammad_backup.sh
    
  • Output:
    # Zammad backup started - Thu Mar  7 03:30:01 UTC 2019!
    
    adapter=postgresql dbname=zammad dbuser=zammad dbpass=xxx
    timestamp is 20190307033001
    backup dir is /var/tmp/zammad_backup
    creating file backup...
    creating postgresql backup...
    could not change directory to "/root": Permission denied
    
    # Zammad backuped successfully - Thu Mar  7 03:33:48 UTC 2019!
    

Steps to reproduce the behavior:

  • create cronjob for backups
  • wait for cronjob to run

Yes I'm sure this is a bug and no feature request or a general question.

@antondollmaier antondollmaier referenced a pull request that will close this issue Mar 7, 2019
@monotek

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

Why would you want to use the root user if the zammad user can do the job?

@MrGeneration

This comment has been minimized.

Copy link
Collaborator

commented Mar 7, 2019

This only applies to the root user, as @monotek already mentioned, the root user is normally not the user you'd want the cronjob run as.

Personally I don't think this is a real issue and I also wouldn't change the script "just because root throws an error".

However: If you want to keep using roots crontab for this backup job, you could put a cd /where/ever/you/please/; /opt..... in front if the main command to ensure you're in the right directory.

https://unix.stackexchange.com/questions/38951/what-is-the-working-directory-when-cron-executes-a-job
Suggests the same. Of course, you can also update your own backup script.

@antondollmaier

This comment has been minimized.

Copy link
Author

commented Mar 7, 2019

Why would you want to use the root user if the zammad user can do the job?

Because it can't, at least according to this:

root@host:~# sudo -u zammad -H /opt/zammad/contrib/backup/zammad_backup.sh

# Zammad backup started - Thu Mar  7 13:12:37 UTC 2019!

adapter=postgresql dbname=zammad dbuser=zammad dbpass=xxx
find: Failed to restore initial working directory: /root: Permission denied
timestamp is 20190307131237
backup dir is /var/tmp/zammad_backup
creating file backup...
tar (child): /var/tmp/zammad_backup/20190307131237_zammad_files.tar.gz: Cannot open: Permission denied
tar (child): Error is not recoverable: exiting now
tar: /var/tmp/zammad_backup/20190307131237_zammad_files.tar.gz: Cannot write: Broken pipe
tar: Child returned status 2
tar: Error is not recoverable: exiting now
ln: cannot remove '/var/tmp/zammad_backup/latest_zammad_files.tar.gz': Permission denied
creating postgresql backup...
Password:

Am I missing something again? The docs don't show any indication, but with "su" involved root is probably the best choice.

Re crontab: That's the current solution and working. I've personally used the approach via cd $(dirname $(readlink -f $0)) approach over crontab, as the "internal" solution allows to run the script from any working directory.

@MrGeneration

This comment has been minimized.

Copy link
Collaborator

commented Mar 7, 2019

Well permission denied simply tells you that the used user doesn't have access.
So you'd basically want to at least chown -R zammad /var/tmp/zammad_backup/ to fix the permissions.

Edit: First permission denied on /root happens, because you're simply doing a "su zammad" while being in /root.

@antondollmaier

This comment has been minimized.

Copy link
Author

commented Mar 7, 2019

Thanks for pointing this out - but I was mostly referring to "su" requesting the password to act as "postgres"-User.

To clarify:

root@host:/var/tmp/zammad_backup# chown -hR zammad: .
root@host:/var/tmp/zammad_backup# ls -la
total 3848776
drwxr-xr-x 2 zammad zammad       4096 Mar  7 03:33 .
drwxrwxrwt 5 root   root         4096 Mar  7 00:05 ..
-rw-r--r-- 1 zammad zammad    1191834 Mar  6 23:10 20190306230953_zammad_db.psql.gz
-rw-r--r-- 1 zammad zammad   99498154 Mar  6 23:10 20190306230953_zammad_files.tar.gz
-rw-r--r-- 1 zammad zammad    5743640 Mar  7 03:33 20190307033001_zammad_db.psql.gz
-rw-r--r-- 1 zammad zammad 3834694693 Mar  7 03:33 20190307033001_zammad_files.tar.gz
lrwxrwxrwx 1 zammad zammad         55 Mar  7 03:33 latest_zammad_db.psql.gz -> /var/tmp/zammad_backup/20190307033001_zammad_db.psql.gz
lrwxrwxrwx 1 zammad zammad         57 Mar  7 03:33 latest_zammad_files.tar.gz -> /var/tmp/zammad_backup/20190307033001_zammad_files.tar.gz
root@host:/var/tmp/zammad_backup# sudo -u zammad -H /opt/zammad/contrib/backup/zammad_backup.sh

# Zammad backup started - Thu Mar  7 13:20:42 UTC 2019!

adapter=postgresql dbname=zammad dbuser=zammad dbpass=xxx
timestamp is 20190307132042
backup dir is /var/tmp/zammad_backup
creating file backup...
tar: opt/zammad/storage/fs: file changed as we read it
creating postgresql backup...
Password:

su: Authentication failure
mv: cannot stat '/tmp/20190307132042_zammad_db.psql.gz': No such file or directory

# Zammad backuped successfully - Thu Mar  7 13:31:11 UTC 2019!

root@host:/var/tmp/zammad_backup#

But sure, if you don't deem this as relevant, let's leave it as it is and I will keep the cronjob with the explicit cd.

@monotek

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

damn, maybe zammad user only works with mysql backups.
sorry, don't realy have the time to look at the code or test it now.

i'll assign to me and do that later...

@monotek monotek self-assigned this Mar 7, 2019

@monotek monotek reopened this Mar 7, 2019

@antondollmaier

This comment has been minimized.

Copy link
Author

commented Mar 7, 2019

Hi,

damn, maybe zammad user only works with mysql backups.
sorry, don't realy have the time to look at the code or test it now.

i'll assign to me and do that later...

No need, I'd be happy to contribute.

To summarize:

  • the backup script should be running with "zammad" user
  • my initial fix is then irrelevant (or at least very low prio)

I'd extend my initial pull request.

@ustange

This comment has been minimized.

Copy link

commented Jun 19, 2019

FYI I'm running 0 */6 * * * cd /opt/zammad/contrib/backup; ./zammad_backup.sh in roots crontab with a PostgeSQL without any problems.


# Zammad backup started - Wed Jun 19 16:30:02 CEST 2019!

creating file backup...
creating postgresql backup...

# Zammad backuped successfully - Wed Jun 19 16:30:18 CEST 2019!
@styleart

This comment has been minimized.

Copy link

commented Jun 21, 2019

@ustange yep, I'm running the same: 30 5 * * * cd /opt/zammad/contrib/backup && ./zammad_backup.sh without any problems. It only fails if using one-command, like 30 5 * * * /opt/zammad/contrib/backup/zammad_backup.sh

@MrGeneration

This comment has been minimized.

Copy link
Collaborator

commented Jul 3, 2019

Merge request is pending internal at the moment.

@MrGeneration

This comment has been minimized.

Copy link
Collaborator

commented Aug 8, 2019

Correction, not internal, but public:
#2509

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.