When I do a lxc file pull from a symlinked file I get the symlink i.s.o. the real file. I used to get the real file before and I am not sure when this behavior started. I see that my snap package is updated to 3.0.0.
I don’t see a flag in the lxc file pull command list, so how can I get the real file out of the container?
Hmm I just checked on my non snap lxd server (lxd v2.21) and there it still works copying the real content of the file i.s.o. the symlink…Something got broken in the snap package maybe?
LXD 3.0 now knows about symlinks and can pull and push them properly, so that’s why you’re seeing this.
I’ve since implemented a few tweaks to that behavior which should be available in the current 3.0 stable snap (unless I forgot to cherry-pick) where passing -r will have lxc dereference symlinks.
lxc file pull -r container/some/symlink blah will follow the symlink inside the container and transfer the target as blah.
Hmm -r seems to work on the snap LXD host, but according to the help -r would mean recursive. So if pulling a directory with -r would also pull all files and subdirs in that directory.
So now I am a bit confused about the -r option. In the v3.0.0 release note it mentions that it supports now symlinks (to stay symlinks) when recursive file transfers are requested. So I would expect the symlink to stay symlink with the -r option. Even if it would be a single symlinked file.
For now it works for my setup, but it looks weird to me 
Hmmm it doesn’t work when giving it a destination name. i.e:
lxc file pull -r nginx/etc/letsencrypt/live/mail.sjomar.eu/fullchain.pem mail_latest.nginx
This will create a directory with the name mail_latest.nginx.
When I do :
lxc file pull -r nginx/etc/letsencrypt/live/mail.sjomar.eu/fullchain.pem .
It creates a file fullchain.pem with the actual contents.
As you can see I use an nginx container with letsencrypt to renew certificates and use them as well for a mail server in another container (I pull the certificate out of nginx and check if it changed. If so I push it together with the key file to the mail container and restart the imap/smtp processes)
edit: I see that the directory it created does hold the actual file though…I can work with that…
Hmm, looks like there’s some other logic misisng in there then, we should make it so that if the source is a symlink to a file, then the target should be treated as the path to a file rather than to a directory.
This entire subcommand is giving me a headache 
Yeah that’s the joy of working with software…it gives you sometimes headaches…sorry I introduced one to yo this time
Thanks for creating a github commit…I am always cautious creating an issue, cause mostly I think I am doing something wrong or don’t understand the way it should work
I’ll await the new snap update to test it again