OK, thanks, I will look into this, modifying where appropriate, one
question, why the bundled file and why the pipe?
Originally this backup package was just a script and some config files, scheduled using cron. But then on macOS I started having to wrap it as an .app in order for the backups to work properly (due to the permission errors).
If I just wrap the script in an .app then the config files wonât be included, so Iâm bundling those (the .config folder). In addition, Iâm also bundling the backup script itself and related files (AUTHOR, VERSION and some additional config files).
The purpose is that then I can just always distribute this .app bundle, even if the target platform doesnât need the .app, and access the script and config files and everything as if it was not an .app bundle in the first place. The .app is just a folder, so I just run the script as if it was in any other folder, it doesnât know about it being inside an .app.
The pipe? I suppose you mean the "|"
in --bundled-file '$(shell find bin/restic -depth 1|paste -sd "|" -)'
. That paste
command concatenates the files listed by the find
command so that the end result becomes like a|b|c
, which is the syntax the --bundled-file
argument takes for specifying multiple files.
I donât have a .config file, is this something generated by restic?
No, itâs entirely custom for my backup script. Since you want to be able to tell the .app what to do, you need to wrap some kind of script.
You can disable SIP if you really want these directories backed up, but really you donât need them. You can cachedir the whole of $HOME/Library
and probably be fine.
I do want at least the mobilesync directory and I have some things in
the âApplication Supportâ directory that I do need. The strange thing
is that if I do an su and run by hand as root, I am pretty sure that
would work, but if I run as a cron job it does not, I will verify that
and get back.
OK, its confirmed, if I actually use su, and I am now in root, and I run the backup shell script that way, it reads all files just fine. If I run it as rootâs cron job, it does not do this. Its very strange to me, but I am no OSX expert.
Well, I seem not able to get the platypus wrapper to work properly. I create using either the command line or the gui, then if I do open /Applications/backup_restic.app as root, I get an error 10810. If I run as myself, I donât get the error, but nothing happens, the script appears not to run. If I run the script by itself, it runs, but with errors as it does not have full disk access as the .app file does.
Any ideas would be appreciated.
When you run it as root and get that error, I think, but am not sure, that the problem is that root does not have a WindowServer running, so thereâs no âconnectionâ between the application that wants a GUI and the window environment, for that user. I have yet to find a solution to that.
When you run the app yourself you should be seeing it running. You havenât described any symptoms though, so you might need to debug it further. Try wrapping just a simple script that creates a file in a known place and nothing more, then see if that file is created when you run the app. If that works, you know the app does run.
The problem is that I would like to run it in some automatic way, so I
donât have to run it manually all the time. I know the script is not
running at all because the first thing it does is to move a file even
before the backup starts and that never happens. I will try a simple
script to see if platypus works at all.
Even the same problem Iâm facing. I tried to resolve it but unfortunately, it is not solving anyhow. I am using the latest version of restic for my Mac and there is an issue. Whenever I tried to open it crashed. This is happening in the last 2 days. I thought it was from the apple side so I contact the apple support team but there is no issue. I donât have any idea how to fix apple application support error. Does anyone know how to solve this?
@jimmy_johnson Please be more specific. Show us the command youâre running and the entire output you get.