Nope. `mount -a` should mount everything listed in /etc/fstab (as I understand it). Assuming it doesn't spit any errors back, you can confirm that it mounted correctly by doing a quick 'ls' of the folder.
Yah... I ran into that tonight. Worked fine last night, but I'd been mucking about and suddenly it didn't. Try unmounting (umount) it, and then remount it using `mount -a` to "mount all".
Ah. I see the problem ;)
That part where it says
{ echo '' ; echo '# Mount CIFS share on demand with rwx permissions for use in LXCs (manually added)' ; echo '//NAS/nas/ /mnt/lxc_shares/nas_rwx cifs...
Dunno, man. Are you *sure* that's line 6? It's more like line 9 or 10 in my /etc/fstab.
There's an error in there somewhere, that wasn't there before you messed with the file, and isn't in mine or others, so it's something on your end.
It looks like you're missing quite a bit:
{ echo '' ; echo '# Mount CIFS share on demand with rwx permissions for use in LXCs (manually added)' ; echo '//NAS/nas/ /mnt/lxc_shares/nas_rwx cifs...
Cool, thanks for that. The SMB/CIFS share I'm connecting to is on my Synology NAS, and I had been using my main/only user for access. Having the login info sitting in plain text in /etc/fstab seemed... wrong ;) After setting up a credentials file, I also added another user 'pve' to my NAS...
I think I found (part of) the problem. For whatever reason, the Debian container was picking up (or assuming) that the DNS server was the same as the DHCP server, and was looking at the right place - the gateway device. The other devices were using the host info for domain name and DNS, as...
So... this started with a default Ubuntu 22.04 LTS container that I couldn't update, because it couldn't 'find' the package repos. I could ping local LAN ip addresses, but not names like 'google.com'.
After further poking around, I found that a default Debian 11 container was able to resolve...
6.3-4, here.
Something weird happened where the physical network interface picked up the same IP address as the bridged virtual interface from DHCP. I think in my case it had something to do with running Ubiquiti Unifi on the local LAN, and 'fixed' addresses (aka DHCP reservations). I had to...
Well... nuts. Misery loves company.
My Proxmox host was up and running last night at midnight, just fine. Finished setting up a new VM (Ubuntu 20.04 LTS server) and mounting an external drive in it that I had passed thru from the host, and went to bed.
Got up this morning... no proxmox web...
Interestingly... Chrome (on the Chromebook) showed as 'up to date' when I checked the version # earlier, but when I went back and 'forced' an update check, it updated to Version 88.0.4324.208 (Official Build) (64-bit). The 'stable' branch on the Chromebook tends to run a tad behind the pure...
Fired up my gaming laptop (Windows 10), and opened up Firefox, Edge, and Chrome and it seems to work fine in those:
Firefox (version 86.0 64-bit):
Edge (version 89.0.774.45 (Official build) (64-bit)):
Chrome (version 88.0.4324.190 (Official Build) (64-bit)):
One thing I found...
Actually, no, it doesn't work in the node summary either.
Yes, Chrome is the only browser option on a Chromebook (though sometimes I wish it had other options). Currently showing 'Version 88.0.4324.186 (Official Build) (64-bit)'.
So... new user here. I noticed that for some reason when I wanted to look at the charts on the 'Summary' section for a given VM, I can't seem to scroll down or see all the chart on the default zoom of 110% on my Chromebook. I had to keep reducing the zoom down to 70-75% before I could see all...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.