/home/user/public_html permissions

Hello,

Thanks, fixed.

Note, I've found that if you run backups, say under user "admin", /home/admin needs to be 711 becuase users need write access to the temp folder. So basically, you can have all users, except accounts that create Bacukps for their users. But you can still set /home/admin/domains to 710 admin:access to still hide his files.

I've created a guide here:
http://help.directadmin.com/item.php?id=254

John
 
I've changed it to set it on /home/username/domains instead of /home/username because of the backups issue. This is cleaner, but doesn't block viewing inside /home/user/* .. however, there really isn't much there (unless the user puts something there world readable)

John
 
I use ftp backup and it works with chmod 710 /home/user

I see you change /home/user to /home/user/domains - but we can chmod 710 /home/user and 711 /home/resellers (and for resellers secure chmod 710 /home/reseller/domains).

Where is reseller list? It's still simple to do.


And why backup needs to have 711? It create backup of domains/mysql/mail and give error on some quota file.
 
DirectAdmin Support said:
We set /home/username/domains to 710,
chown username:access
Click to expand...
John, I'm either missing something or confused.

Why does setting /home/username/domains to 710 do anything to mail at all, since mail uses /home/username/Maildir and /home/username/imap?

Thanks.

Jeff
 
It doesn't do anything for mail on domains, but leaves the opportunity to still throw in on /home/user if we change the script at all. The backup issue is in regards to other users, backing up on yourself doesn't have an effect. Also, it wouldn't be affected by ftp backups because they're assembled in /home/tmp/admin/user. Local backups are affected because they're assembled in /home/admin/admin_bacukps/user (for example) . We can still test more and change/improve as needed. And yes, I agree it's not difficult to change the script to check for Resellers/Admins. Probably a proof of concept test would be good for now, then we can get into more detail once potential issues are found/resolved.

Thanks!
John
 
Hi John,

Since implementing this on our servers, we've had issues with adding and deleting user accounts properly. It seems any loading of files placed within the public_html of new sites isn't loading properly. It continuously redirects everything back to the default login/control panel page for our main system account. I've verified DNS to be rolled over properly and everything is definitely resolving to our servers and IP's. I even manually forced /etc/hosts to point to the correct IP for the domains I added, as well as my local hosts file on my Windows machine to ensure there was definitely no remaining resolver issues.

Additionally, upon deleting an account, not everything is cleared out as it should be. The /home/user folder still exists with all the subfolders within (no files though), as well as the data folder of the user inside /usr/local/directadmin/data/users. Even after manually deleting these two locations, if you attempt to re-add the account to the server, it spits back:

Code: 
Cannot Create Account
 
 
 
Details

That username already exists on the system

I would greatly appreciate any suggestions from anyone having the same issues as I am. I should also note, I implemented this upon your first post before the corrections were made and the knowledge base entry was created (which was causing forbidden errors, so I had to manually chmod everything back to how it was to get it working again). I since modified it to match everything in the kb entry and it seems it works great. Only minus the adding and removing of user accounts now.

Any ideas? Thank you. :)
 
Hello,

I'm not sure how it would be related to anything with DNS.. that may be a seperate issue. Also DA logins should't be affected by this either since the home directory isn't checked/required for DA logins really (unless I'm missing something). Double check the disk isn't full.

However the removal of User is most likely related to this change, so I'll be looking at it while I code this directly into the DA binaries as a new feature.

John
 
Thanks for looking into this.

It does not appear to be a disk space issue, "df" reports over 50 GB left on the primary drive. Not a quota issue either, so I'm stumped as to why it did this.

Good news though, I solved the user issue by "userdel -r user" eventually. This is the ugly way to do it, but it worked. There were also remnants in such places as /var/spool/mail/user, /etc/virtual, and a few other places, but I removed those prior to removing the user permanently from the system. After all this, I can re-add the domain and user just fine in DA now.

I am still struggling with why it will not load the public_html files when loading the domain in the browser (again, it goes to the CP login page, and the IP's are resolving correctly as expected). Yet somehow it DOES work when I use http://www.servername.com/~user. Now that's random.

It also looks like I can now add/remove users again just fine, although I didn't change anything to fix it. Maybe it was just a one time thing. I did notice the newly added /home/user is set 711, when all previous are 755. I thought the 710 (or 711) perms were only applied to /home/user/domains now? Maybe I am just nuts and did not understand this correctly or have something still set from the originally suggested shell command and custom modifications. Thanks again for your help.
 
I've set secure_access_group=access, as described on page http://directadmin.com/features.php?id=961

After that, I'm not able to get access to my emails via POP3/IMAP4.
I've got errors:

Apr 21 13:38:07 gw2 dovecot[3851]: Fatal: chdir(/home/userdomain/imap/userdomain/alexandr) failed with uid 1007: Permission denied
Click to expand...

on our System user with uid 1007 is majordomo

Code: 
# grep 1007 /etc/passwd
majordomo:*:1007:1:User &:/etc/virtual/majordomo/majordomo:/bin/sh

Adding majordomo to additional group access does not help.
chmod 711 /home/userdomain helps...

What is wrong?
 
Hello,

As I noticed when implementing the feature, for some reason the services need to get a full restart before new permissions are seen.. I'm not sure why this is, possibly something with a system cache.

Adding majordomo to additional group access does not help.
Click to expand...
it should.. just double check it's added:
Code: 
grep access /etc/group
and restart exim.

John
 
Just the same. Restarting of exim and dovecot does not help, even with kill.

Code: 
grep access /etc/group
access:*:1030:apache,nobody,mail,majordomo

But why Exim? Exim seems to me to work fine both with 711 and 710. No errors found.
The problem is to read the dilevered email via POP3/IMAP.
 
Try adding the daemon user as well.

Try restarting dovecot, or vm-pop3d and xinetd. (depending on which you have)
However, majordomo doesn't have anything to do with accessing pop/imap, hence I'd be confused as to why that user would be related to pop/imap.. hence I assumed it's exim.. as exim is what controls majordomo.

John
 
Thanks for your help, John.

My mistake. It's hard to remember why, but I had wrong uid (1007) for the user in /etc/virtual/userdomain/passwd. I've corrected uid, and now it works fine. Possibly the reason is in manual transfering the user from another server.

Regards,
Alex Gr.
 
Another problem has occured with spam delivering to system (default) e-mail for account. There're no problems with not-spam emails to such an e-mail.

Here, what we have in logs:

Code: 
2009-04-22 14:50:30 /home/200172/Maildir/.INBOX.spam/new/ <[email protected]> R=domain_filter T=address_file defer (13): Permission denied: while creating file /home/200172/Maildir/.INBOX.spam/new//temp.49063.ns2.hostname
2009-04-22 14:51:46 /home/200172/Maildir/.INBOX.spam/new/ <[email protected]> R=domain_filter T=address_file defer (13): Permission denied: while creating file /home/200172/Maildir/.INBOX.spam/new//temp.74141.ns2.hostname
2009-04-22 14:54:52 /home/200172/Maildir/.INBOX.spam/new/ <[email protected]> R=domain_filter T=address_file defer (13): Permission denied: while creating file /home/200172/Maildir/.INBOX.spam/new//temp.36963.ns2.hostname


Already checked permissions on directory. Everything seems to be fine.
 
More information:

It does not matter to what e-mail address a message is sent.
If we set "Redirect spam to the catch-all ~/.spamassassin/spam folder.", we have the situation, described above on some accounts. No problems with others.

Double checked directory permissions manualy and with set_permissions.sh maildir <user> <path/Maildir>. Nothing helps.
 
Another problem has occured. Majordomo is not anymore able to read restrict_post file placed in user's home dir:

Code: 
MAJORDOMO WARNING (mj_resend)!!

Can't read /home/userhome/allowsendaddress.txt: Permission denied

added majordomo to access group:

Code: 
grep access /etc/group
access:*:1172:apache,nobody,mail,majordomo,daemon


permissions checked:

Code: 
ls -l /home/userhome/allowsendaddress.txt
-rw-r--r--  1 userhome  mail  15 23 апр 13:25 /home/userhome/allowsendaddress.txt
 
Hello,

Thanks, I've added majordomo and daemon to the users in the access group.
Available for the next release of DA.

John
 
Hello, John.

Does that helped you? In my case adding majordomo and daemon to the users in the access group did not helped. I don't know why.

The problem is still not solved on my FreeBSD boxes.
 
Hello,

We still have got the issue with majordomo. So the question is:

Why majordomo is running processes with group daemon? Would it break anything, if we run it with group access?
 
You must log in or register to reply here.
Back
Top