Usr ports updating permission denied

All you have to do is include it in the --user swith when you run the script.

As @clarkej accurately points out, I do in fact add the user when I am on a paid production server like Interserver, Hostwinds, or Digital Ocean where I have root access.

pkg: file:///usr/ports/packages/meta.txz: No such file or directory repository local has no meta file, using default settings pkg: file:///usr/ports/packages/packagesite.txz: No such file or directory Unable to update repository local [[email protected] ~]# when opening the file. If you are new to vi, you will mess it up, and not just once.

Some info to use vi is available here: Vi reference guide No shame in being new, everybody was at some point I typed in nano in the command line and it took me a new window called new buffer.

The way bench is designed, it wants the user owning ghe account to be the one executing commands.

So you are logged into the server as user “felix” and you are attempting to run bench commands that are owned by “frappe.” GCP only lets you log in as your default user, so you can never really own the “frappe” account.

Possibly you installed as root, so perhaps you can fix ownership with chown?

The issue seems to have been fixed as i just ran the command and the update worked.

usr ports updating permission denied-47

So unless i am missing something here, there is something uncanny about the way GCP handles ERPNext when it comes to user permissions.

I have been down this road and tried running “chown” to take possession of the frappe account and it never really worked.

The ONLY way to be able to run bench commands on the Google Cloud Platform is to install ERPNext using the following command: At this point all of the frappe framework and erpnext apps will be installed in your “felix” user account. Unless you can get Google to unlock some port numbers, I doubt you will have very much luck using Lets Encrypt certificates. It also means that you will not be able to get any of the email functions to work either.

The point made here suggests that with sudo privilege added to the default user created by GCP (which in this if the first part of your account email as noted above), for commands such as bench update, you don’t have to initiate the command by adding “sudo” at the beginning of the command as the user assumes sudo privileges already.

However, i have set up several ERPNext instances on GCP and each time i try to run scripts such as updates, upgrades or even renew ssl certificates, i always hit a permission denied error.

Leave a Reply