On Wed, Mar 9, 2016 at 2:43 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/09/2016 01:11 PM, Greg Freemyer wrote:
# NFS MOUNT HERE 10.200.3.230:/mnt/pacers1/kvm672/kvm672 /srv_new nfs rw,relatime,vers=3 0 0
# NFS dependent mounts here /srv_new/sftp-container-large /srv/sftp ext4 nofail,loop 0 0 /srv_new/portal_backup_container /home/portal_backup/portal_backup ext4 nofail,loop 0 0
Oh, I see what you're doing! I woud;'t do it that way.
back in the 1980s working with SUN workstations and *EVERYTING* being NFS it was done with symlinks.
When I did similar on opensuse with my laptop connected to the home LAN I worked it out this way:
I had a /mnt/nfs/ main directory had under that things like
/mnt/nfs/homelan/downloads
So there was a
homelan:/home.anton/dowloads /mnt/nts/homelan/downloads nfs \ rw,rsize..,wsize...,_netdev 0 2
There was also
awaylan:/yamma/yamma/dowloads /mnt/nts/homelan/downloads nfs \ rw,rsize..,wsize...,_netdev 0 2
I then had symlink from /home/anton/downloads to /mnt/nts/homelan/downloads
If I was working in a coffee shop and didn't have a connection to neither homelan nor awaylan then my downloads directory appeared empty.
You seem to overcoming a different problem than the one I have. My NFS mount should be reliable. The NFS server and the client are both in a data center (in the cloud) This issue apparently came up because one of my container files somehow got deleted. (I haven't looked into that at all. It held backups from a third cloud VM, so I do want it to be reliable.)
The "_netdev" is important.
I'm testing now. How long should the _netdev mounts take to mount? After reboot I immediately logged in: the NFS mount is in place but the _netdev mount of /srv/sftp is not. It has been 20 minutes since reboot, so even the 15 minute point has passed? I'll keep watching.
The symlink avoid the bind mount that seems to be giving you problems.
I'm not doing bind mounts. They are loopback mounts. If you don't know what those are, an example is mounting an ISO image to allow files to be accessed inside the ISO.
===
The NFS server doesn't allow me to control of the file metadata (ownership etc.). In particular it forces all files on it to be owned by one UID / GID.
So as root I've created a couple large container files which I mount via loopback. Within the containers I have full control of the filesystem metadata (file ownership, etc).
I take it to mean that you can't run rpc.imapd ? You do realise that imapd allows *arbitrary* remapping of uid and gid?
So if the remote files are 'owned' rw-r----- by hpotter;gryffindor you can map them to, for example, gregf:users
The biggest thing I have on the NFS partition is a SFTP folder structure. One folder for each of my clients. # mkdir -p /srv/sftp/<USER>/incoming # mkdir -p /srv/sftp/<USER>/outgoing For each client I create a Linux account with a /sbin/nogin shell. # useradd -g sftpusers -d / -s /sbin/nologin <USER> I make each client the owner of the folder their files are in # chown -R <USER>:sftpusers /srv/sftp/<USER>/* # chmod 555 /srv/sftp/<USER>/outgoing Thus I need to have numerous UIDs as owners of files on the NFS mount. I don't think imapd can let me do that. FYI: My provider specifically doesn't allow that. They force all files created to be owned by one specific UID. I think they do that so they can sell more functional disk space at a higher per GB price. I pay the "backup space" rate. I overcome the single UID limitation by creating a large container file. I think I did # dd if=/dev/zero of=/srv_new/sftp-container-large count=1 seek=300GB # mkfs.ext4 /srv_new/sftp-container-large Then I do the loopback mount I showed in my fstab. With the new mount point I have full ability to create my SFTP folder structure. Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org