Ownership Issue on WordPress

Yes. John it would be nice if you could think with us here :). I also found out that chmodding 711 takes away the whole access effect.
Though resellers/admin have their /home/usermap chowned 711 too, but the dir domains for example chowned diffrently then a user. (also a good thing to know, chown 710 files in /home/admin/ if you have any)
Well whats sure its thats a permissions chmod problem, I don't understand where it goes wrong.
 
Last edited:
Yes, but in combination with mod_ruid it apparently gives problems. I can understand that, but that feature makes sure users cant see in other users files. Without it, in ssh a user can nano someone elses config.php and see their mysql password.

Default I don't give users SSH, but it is a security risk. Right now I keep it enabled, I'd rather have this security fixed and /~user disabled.

But as I understand it Scolpy, you have both and no problems? Then there must be something else going on.. however it should be related to this :confused:

Scolpy if I may ask what OS are you running?

Yea, I'm using both of them and I don't have any problems.

My OS is CentOS 5.5 Final 64bit.

Maybe Scolpy is using also mod_ruid instead of mod_ruid2 ?
Also maybe the files/dirs in public_html are not owned by the user, but probably root or something else then the user ?

I'm using mod_ruid2.


P.S.
Just know when you run the set_permission script, it's disable the secure_access_group effectiveness and you need to run command:
Code:
echo "action=rewrite&value=secure_access_group" >> /usr/local/directadmin/data/task.queue
again.
 
I'm using Debian 5 64bit. And yea I've ran that rewrite line. I also think it possible runs that automatically if it sees the permissions are not set that way.
 
I did some more testing and came to the following:

When I set in httpd.conf the line to:
RUidGid apache access

Everything works. However, when I check which user runs the script with exec(whoami), under ~/username it says apache, under domain.tld/ it says its own username.

Which leads me to assume that RUidGid is set for apache/access on main config/requests, and is being overruled by a user httpd.conf, on a domain request, since RUidGid admin admin is being executed on a virtualhost containg a ServerName domainname.tld.

What I wonder if this is the same with you daveyw and scolpy. If so, it means that the mod_ruid functionality doesn't work on /~username. (?)
 
However I believe you can teach the user to change ownership through the DirectAdmin Files facility.

Jeff

So, I am a total novice when it comes to code or dev of any type! I am helping out a friend who is using DirectAdmin for the WordPress site she started. The WP loads file in the "backend" UI but the actual posts & pages never show up.

After reading you suggestions - I went to the FILES section but there is no option/drop down/etc to change the user ownerships that I can see?!

Any additional info or help would be super appreciated!

Thanks j-)
 
This thread is more for systems people who have access to the server. I'm looking right now at the DirectAdmin file manager. Files and Directories for which you can reset the user have checkmarks at the far right. Go ahead and check the ones you want to reset.

Then at the bottom of the page click on Reset Owner

If for some reason you can't do this you or your friend will have to contact the hosting company which hosts the site. That's not us.

Jeff
 
We have WP installed personally, and when upgrades (main package and plug-ins) are available, it is all FTP related.... So, if the file uploads use this method, which, sadly it doesn't, then it will render this issue extinct.
 
As I understand it the issue is because posts added through WordPress may use the httpd user, while everything uploaded by the user (ftp or file manager) are uploaded as the user.

I'm not sure what you mean, Peter, since both ftp and the file manager upload as the user.

Jeff
 
I'm not sure what you mean, Peter, since both ftp and the file manager upload as the user.
I guess he means that if you are installing WP with HTTP (instead via FTP) and doesn't run mod_ruid/mod_suphp it will be upload as 'apache' and not the user.

You can fix this issue easly with installing mod_ruid and some modifications at the httpd.conf templates as I've posted already in this thread.

FYI: Maybe (for everyone) this can be usefull: http://www.directadmin.com/features.php?id=956
 
What I mean by FTP is, the script grabs updates (externally) then it uses a FTP routine internally (need to give it your ftp details of course), then it uses that, thus perserving the user:user owned files ...... See attached grab
 

Attachments

  • WPFTP.jpg
    WPFTP.jpg
    45.2 KB · Views: 152
See the reply immediately above yours, by user daveyw. Doe sit resolve your problem?

Personally we've been running suPHP rather than mod_ruid.

Before we started using suPHP on DirectAdmin serves we ran cronjobs (as root) for our users to change the user permissions regularly to what they needed to be.

Jeff
 
I have no problem, if you're asking me? I was just expressing how WP updates itself - which most scripts should do (if running mod_php)...... Sorry to confuse people.
 
Back
Top