You start the service on behalf of the root. therefore, the file belongs to the root.
teamcity-server in this case run from the service user, for example, teamcity
sudo useradd -m teamcity sudo chown -R teamcity /opt/TeamCity sudo chown -R teamcity /opt/.BuildServer
create a file /etc/init.d/teamcity and register
#!/bin/sh # /etc/init.d/teamcity - startup script for teamcity export TEAMCITY_DATA_PATH="/opt/.BuildServer" case $1 in start) echo "Starting Team City" start-stop-daemon --start -c teamcity --exec /srv/TeamCity/bin/teamcity-server.sh start ;; stop) echo "Stopping Team City" start-stop-daemon --start -c teamcity --exec /opt/TeamCity/bin/teamcity-server.sh stop ;; restart) echo "Restarting Team City" start-stop-daemon --start -c teamcity --exec /opt/TeamCity/bin/teamcity-server.sh stop start-stop-daemon --start -c teamcity --exec /opt/TeamCity/bin/teamcity-server.sh start ;; *) echo "Usage: /etc/init.d/teamcity {start|stop|restart}" exit 1 ;; esac exit 0
give rights at the end
sudo chown -R teamcity /opt/TeamCity sudo chown -R teamcity /opt/.BuildServer
as for the second question, I see 2 solutions
1) copy the entire project to a different configuration, specify the default brunch, specify the specific steps ...
minus in that. what do you need 2 conf-ii support
2) take the name of the barancha from the parameter teamcity.build.vcs.branch.<VCS root ID> , you can read in detail here , and use it in the Command Line for verification. if master, then execute it, if dev, then another
UPDATE
Why is this happening and what to do so that would not change the rights to the directory and files.
if the service is not run on behalf of the superuser, then you are more likely to be unable to execute some commands on the machine, since there will be no rights to perform.
Instead of a user teamcity, you can specify your own, or add to the group where you enter.
