yajo
commented
6 years ago Yikes, this seems related with the recent #109 that broke travis
Closed lasley closed 6 years ago
yajo
commented
6 years ago Yikes, this seems related with the recent #109 that broke travis
yajo
commented
6 years ago I have tested and I cannot replicate your problem. I think you looked for the user groups in the wrong place:
odoo@39cc77e9d184:/opt/odoo$ grep odoo /etc/passwd
odoo:x:1000:1000::/home/odoo:/bin/falseI repeated all of your steps and all produced the expected results. I'm suspecting there might be a AppArmor/SELinux/OS/package problem. Are you by chance using Ubuntu in the same version as Travis does?
yajo
commented
6 years ago 
lasley
commented
6 years ago @Yajo /etc/passwd is the user definition file, /etc/group is the group. Here's some good reading (I threw in the shadows file too):
I'm suspecting there might be a AppArmor/SELinux/OS/package problem. Are you by chance using Ubuntu in the same version as Travis does?
Yeah, this was on Ubuntu 16.x LTS. I just tried on Mac High Sierra and cannot reproduce the issue.
109 was fixed, does this still happen to you?
It is still readily reproducible on Ubuntu. You're probably right then, although I'm somewhat confused as to why AppArmor on the host system would be interfering with something in the Docker namespace. I don't see any logs either, but it's possible those are disabled. This is the /etc/apparmor.d/docker though:
profile docker-default flags=(attach_disconnected,mediate_deleted,complain) {
#include <abstractions/base>
network,
capability,
file,
umount,
deny @{PROC}/* w, # deny write for all files directly in /proc (not in a subdir)
# deny write to files not in /proc/<number>/** or /proc/sys/**
deny @{PROC}/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9]*}/** w,
deny @{PROC}/sys/[^k]** w, # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel)
deny @{PROC}/sys/kernel/{?,??,[^s][^h][^m]**} w, # deny everything except shm* in /proc/sys/kernel/
deny @{PROC}/sysrq-trigger rwklx,
deny @{PROC}/mem rwklx,
deny @{PROC}/kmem rwklx,
deny @{PROC}/kcore rwklx,
deny mount,
deny /sys/[^f]*/** wklx,
deny /sys/f[^s]*/** wklx,
deny /sys/fs/[^c]*/** wklx,
deny /sys/fs/c[^g]*/** wklx,
deny /sys/fs/cg[^r]*/** wklx,
deny /sys/firmware/efi/efivars/** rwklx,
deny /sys/kernel/security/** rwklx,
# suppress ptrace denials when using 'docker ps' or using 'ps' inside a container
ptrace (trace,read) peer=docker-default,
}Well, Docker does many rooty thingies, and a good way of blocking them is precisely AppArmor or SELinux.
I'm more a SELinux user, so I don't really know how to help you, but my first guess would be to just disable apparmor (there must be a way) and try again. If the problem goes away, you know the culprit now.
In any case, there are no mounted volumes, so I don't know why should that interfere... However I noticed there's no build step in your STR. Is it possible that you're using an old version? Try a docker-compose build --pull before.
lasley
commented
6 years ago Oops forgot to report back on this yesterday. I disabled AppArmor and am seeing the same results.
However I noticed there's no build step in your STR. Is it possible that you're using an old version? Try a docker-compose build --pull before.
I didn't specifically pull, but I'm pretty sure I saw it pull (I have docker-gc running pretty liberally on this box). In the interest of leaving no stone unturned though, I did a docker pull tecnativa/odoo-base:9.0 then the replication steps again.
Pull and subsequent build confirmed, issue still present (AppArmor still disabled) 😦
yajo
commented
6 years ago Could you try docker image rm tecnativa/odoo-base:9.0 (and other tags) and then docker-compose build --pull?
lasley
commented
6 years ago Still getting the same results unfortunately. Here's the output:
yajo
commented
6 years ago Amazing, I do exactly the same commands and it works perfectly... Let's debug even further:
LOG_LEVEL=DEBUG to build args in the docker-compose.yml file and provide build logs.docker-compose run --rm --no-deps odoo ls -lZARI want to check permission and labeling issues.
BTW, to reduce cluttering: https://gist.github.com/ericclemmons/b146fe5da72ca1f706b2ef72a20ac39d 😉
MaskedBelgian
commented
6 years ago Did you try to update the Base module ?
I had an issue where after a migration from V8 to V9, Odoo couldn't reach any ressources.
-u base solved this issue.
Maybe the image of odoo9 we pull should be updated ?
lasley
commented
6 years ago @MaskedBelgian - there is no database at this point to upgrade. Odoo is failing to launch due to permissions issues on the sources directory.
@Yajo - logs below:
yajo
commented
6 years ago Thanks, @lasley. These logs expose some interesting details that can lead you to hints:
? where the security context should be. This could be a problem if you're under an AppArmor/SELinux-enabled system. However, I'd say it isn't your case, since ./custom/src) is the most interesting one. I see some .DS_Store files that appear. It leads me to think that you are mounting some folder from a mac filesystem into the ubuntu VM. Maybe the mac file system doesn't support some feature Docker needs.d????????? and Permission denied are most clear. Well, ./custom/ssh: Permission denied is expected, but the others are not. You can try with docker-compose run --rm --no-deps --user root odoo ls -lZAR to see if root has access. If it has, it can be a permissions problem. If it still does not, it can be a disk corruption/misconfiguration problem. You can check https://serverfault.com/questions/18110/permission-denied-to-a-file-i-own too.I hope something of all of that helps...
lasley
commented
6 years ago I noticed the .DS_STORE files as well, and was coming to a similar conclusion. The only thing that made me not say something earlier is that this works absolutely fine if I build and run on my Mac. The more weird thing is that the drive is a network share, mounted via NFS on both sides.
I went ahead and cloned the repo directly to the VM drive and was able to run it without issues.
I'm inclined to call this fixed - it's something I can easily work around on my end. Thanks for the assistance 😄
I wonder though what is actually causing this issue (is it NFS specifically, or is Moby confused into thinking it's a Mac volume due to the index files). It's a Moby issue regardless I think, but it would be really nice to know.
So I finally was getting around to switching over from my fork, and I'm noticing a permissions issue on the source directories, which causes the following error:
Replication steps:
And here's why:
Interestingly, logging into root then su-ing over it's fine:
It looks like Odoo is not part of the proper group if catting groups:
But
groupscommand shows otherwise:So yeah that's about how far I've gotten. I'll report back when I find a solution.