Proxmox + OwnCloud

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Shankar

New Member
Feb 22, 2018
12
2
3
40
A quick read on this? Kerunix

Also if you are confident about the security you can choose to turn that off.
Thank you for that link, I've come across some of such posts too. I finally tried it, but that didn't help either. All my clients for NFS are on my internal network, so, I have apparmor disabled on a couple of my containers. That said, I prefer to not do it as a fan of doing security right.

I have this on my /etc/apparmor.d/lxc/lxc-default-with-nfsd on both Proxmox host and my NFS VM -
# Do not load this file. Rather, load /etc/apparmor.d/lxc-containers, which
# will source all profiles under /etc/apparmor.d/lxc

profile lxc-container-default-with-nfsd flags=(attach_disconnected,mediate_deleted) {
#include <abstractions/lxc/container-base>

# the container may never be allowed to mount devpts. If it does, it
# will remount the host's devpts. We could allow it to do it with
# the newinstance option (but, right now, we don't).
deny mount fstype=devpts,
mount fstype=nfsd,
mount fstype=rpc_pipefs,
mount fstype=cgroup -> /sys/fs/cgroup/**,
}
And this on my CT conf on /etc/pve/lxc/<ctid>.conf
...
###### NFS OPTIONS ######
## Enable NFS
lxc.aa_profile = unconfined
lxc.aa_profile = lxc-container-default-with-nfsd
###### END NFS OPTIONS ######
Restarted NFS, and CT/VM, still get a connection failed from the client to either the CT/VM NFS server.
 

msg7086

Active Member
May 2, 2017
423
148
43
36
You can try narrowing down the problem by disabling the apparmor and see if it makes the difference.
Control variables helps ;)
 

Shankar

New Member
Feb 22, 2018
12
2
3
40
You can try narrowing down the problem by disabling the apparmor and see if it makes the difference.
Control variables helps ;)
Yes, I tried that too, disabled apparmor completely, that didn't help, for both CT/VM. I also set up nfs server on proxmox host directly, I still have the same access denied issue. Not sure if it's the server or the client that's causing the problems, nothing shows up in syslog when the connection is made and access is denied.
 

msg7086

Active Member
May 2, 2017
423
148
43
36
Can you try to set up a fresh debian kvm as a nfs client? This should rule out potential client issue if any.
 

Monoman

Active Member
Oct 16, 2013
408
160
43
I'd do as msg7086 said, create the same or similar setup in a kvm instance and see if you can replicate the issue.

Just to be 100% clear... What IP address are you intending on serving NFS off proxmox from? What IP address is your CT/KVM client IP to receive it from? What's the IP for the CT/KVM of OC/NC? Your CT/KVM should have two network devices.
 

Monoman

Active Member
Oct 16, 2013
408
160
43
one should be used for "production" and one for "NFS" from the proxmox host to the CT. imho
 

Shankar

New Member
Feb 22, 2018
12
2
3
40
Managed to resolve my NFS issues, TL;DR - On Proxmox host, add the following lines to /etc/apparmor.d/lxc/lxc-container-default-cgns below the line deny mount fstype=devpts, -
mount options=(rw, bind, ro, rslave),
mount fstype=nfsd,
mount fstype=rpc_pipefs,
Reload the profiles with
apparmor_parser -rv /etc/apparmor.d/lxc-containers
That solved all of my mounting problems I've had so far with NFS.

I now have NFS servers running on CT, VM, and Proxmox host, and can mount them on any system without issues. Don't need to disable apparmor on CTs, or add any custom apparmor profile to run NFS server. This approach applies to all CT/VMs from what I can see. The mount options was causing the access denied error, I found the solution here - How to enable bind mount inside lxc container · GitHub

Coming back to the NextCloud part, the problem I'm running into is with NTFS, Linux systems don't have the ability to implement ownership/perms on top of NTFS, so the ownership and perms that the disks are mounted as on the host are carried over through the bund mounts or NFS server, or any other mechanism. In my case, it's root:root with 777 perms when mounted on Proxmox. That is why I can't change any perms on any mounts either through CT/VM/direct. I think I'm going to have to convert my NTFS partitions to EXT at some point. I'm still trying to figure out how to make all my data available via NC, I'll update this thread with details when I get that done.

When using NTFS, you also need to look out for readonly mounts, which happens when Linux perceives NTFS as unclean, and disables writes. The only solution is to take the disk back to Windows, chkdisk on it, and bring it back to Linux. More details here - Can't mount NTFS partition with write permissions.

As for /etc/exports, both IP notations work - /255.255.255.0 and /24. They're essentially the same, and /24 is easier to type and maintain.
 

Shankar

New Member
Feb 22, 2018
12
2
3
40
I'd do as msg7086 said, create the same or similar setup in a kvm instance and see if you can replicate the issue.

Just to be 100% clear... What IP address are you intending on serving NFS off proxmox from? What IP address is your CT/KVM client IP to receive it from? What's the IP for the CT/KVM of OC/NC? Your CT/KVM should have two network devices.
I did create a brand new KVM, still ran into the same issue. Setting up the NFS server was easy. Mounting the exports from clients gave me access denied.

For NFS servers, Proxmox host is on 108, CT is on 242, and VM is on 120, all on the same network, served from same IPs. Clients on the same network too, no firewalls. Clients can list all mounts on any of those IPs, but they'd still get an access denied when trying to mount.

P.S. I don't still have the issue, I'm just responding to the question as it stood before the issue was resolved.
 
  • Like
Reactions: Monoman

msg7086

Active Member
May 2, 2017
423
148
43
36
A KVM NFS client rules out client issues.

Turning off apparmor on proxmox should reveal the issue that you discovered.

Glad you solve the problem XD