nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OD folder permission issue

droog

We are noticing, intermittently, that the permissions on folders on our webservers are being changed to "root" ownership and the group is either being changed to "root" or "other". The problem is that we are specifiying a different ID to deploy with. All of our deployments use non-root credentials and this has been setup and working successfully for some time. I don't have any good logs to provide because I can't reproduce the problem and I don't have a good idea as to when it started. Any ideas?
TS 671 SP1 on Windows2003
OD 6.1.1 Base on Windows 2003
OD 6.1.1 Receiver on Solaris10

Find more posts tagged with

Comments

Adam Stoller

We are noticing, intermittently, that the permissions on folders on our webservers are being changed to "root" ownership and the group is either being changed to "root" or "other". The problem is that we are specifiying a different ID to deploy with. All of our deployments use non-root credentials and this has been setup and working successfully for some time. I don't have any good logs to provide because I can't reproduce the problem and I don't have a good idea as to when it started. Any ideas?
TS 671 SP1 on Windows2003
OD 6.1.1 Base on Windows 2003
OD 6.1.1 Receiver on Solaris10

If OD is running as non-root on the receiver, it should not be able to set folder ownership to root there. Are you sure it's running as non-root on your receivers?

droog

OpenDeploy is running as root on the receiver. Under permissionRules in the deployment we are specifing a unique id for the deployment to use.

Adam Stoller

OpenDeploy is running as root on the receiver. Under permissionRules in the deployment we are specifing a unique id for the deployment to use.

I'm confused - you say the deployments are running as non-root, but the receivers are running as root?

When a sender is running as non-root, it can only deploy as the user who is the owner of the process, but if the receiver is running as root, perhaps the user/group that is being used on the sending side doesn't exist on the receiving side - and thus the receiver might be defaulting back to root.

Make sure that user/group and UID/GID values of the sender are the same on the receiver.

Failing that, you'll probably have to go through Support so that they can either reproduce it, or see it reproduced in your environment.