[qubes-users] Re: Recreate boot content
I don't know if I mistakenly clear that boot loader. But I'm pretty sure that's not related to qubes. Do you think it is possible to recreate the boot partition or should I start over with the install? Install is the worst scenario since I've been configuring for a long time. Thank you! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7173347f-3505-4124-b283-2548a035b0ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Question before buying a new laptop
On 10/06/2018 03:07 PM, ben.thomp...@vfemail.net wrote: > Thanks for your reply. > >>> I have a few questions: >>> How well does passing a dedicated graphics card to a vm work / is gaming >>> in a vm feasible or do i still need dual-boot? >> >> Yeah very feasible many people do it including me. > > So what games are possible and are you using a windows or linux guest? > (Sadly there are games not running with wine.) Windows without networking to avoid the spying features. There are however a variety of AAA DRM free games that run native on linux these days. On my KGPE-D16 I just finished the two wolfenstein games and the new prey on max settings I have RX580 and 6328 cpu with 14gb ram assigned to the VM. I suggest purchasing 8gb ecc rdimm sticks as they are the most affordable per gb if you get one. The KCMA-D8 is also a good choice and with that you don't have to deal with NUMA issues. > >> Of course you need the right system you would need an eGPU capable >> laptop such as the W520 which you should install an quad core ivy bridge >> cpu in so you get pci-e 3.0 for the expresscard slot. As always I >> recommend installing coreboot - the ivy/sandy coreboot port has open >> cpu/ram init and supports me cleaner to nerf your me (again disabling is >> impossible) > > Well the W520 is from 2011 and can't be bought anymore and i don't like > to buy hardware second hand. Whats wrong with second hand hardware? You can replace the worn out parts like the keyboard/armrest/lid very easily to the point where you couldn't tell the difference between a new and used laptop. I don't think a circa 2013 cpu is that bad considering what you gain from using it. > Also the processor is a bit weaker. A quad core ivy bridge cpu will be fine I guarantee it. > I know the problem with new CPUs is a ME which can't be properly > deactivated anymore (at least as far as i know), but it seems i have to > accept this, if i want a powerful processor for gaming / work. No you don't have to. What do you want to run that couldn't run on an older laptop but could run on a newer one? > Hence the W520 is not really an option for me (Although it is the better > option from a security standpoint). > > So do you have a suggestion for newer hardware in the same price-range? I don't recommend blatantly insecure hardware which is what new x86 is - it is all junk. See for instance the recent china spying scandal where they inserted a backdoor chip on the motherboard and that is probably just the tip of the iceberg. The future of real owner controlled, open source firmware, high performance hardware is non-x86, such as POWER systems like the raptor talos 2, raptor blackbird, etc. Of course made in usa is a must for security reasons and the OpenPOWER9 CPU's are made here as well as those boards. I hope that xen/qubes will soon support POWER - but I argue that POWER-KVM is more secure than xen on a black box x86 platform. In terms of gaming you aren't going to get good performance on a laptop which is why I always suggest obtaining an owner controlled no psp/me libre-firmware available desktop system board like the KCMA-D8/KGPE-D16 (runs qubes 4.0 great) plus a g505s for your no psp/me owner controlled laptop which has open cpu/ram init via coreboot. For laptop gaming via eGPU you can re-direct the output to the internal screen if both the iGPU and the eGPU are assigned to the same VM - very difficult though and of course graphics assignment weakens your security in a variety of ways so I would simply have a dedicated gaming device if you can afford it. Let me know if you find this advice helpful - I am always pleased to answer the expert questions. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/105b2ee6-b32e-7d7e-52fd-d5eb9c48509a%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] nftables vs iptables
On 10/9/18 7:44 PM, mfreemon wrote: On 10/8/18 10:56 AM, mfreemon wrote: On 10/2/18 2:25 AM, Ivan Mitev wrote: On 10/2/18 1:32 AM, Chris Laprise wrote: On 10/01/2018 05:48 PM, mfreemon wrote: On 1/11/18 3:01 PM, Chris Laprise wrote: > On 01/10/2018 03:47 PM, Connor Page wrote: >> The official templates use nftables so shouldn’t be mixed with iptables. I didn’t have time to learn about nftables, so just removed nftables package from debian 9 template. YMMV. > > Hmmm, I was just thinking how Qubes' own guest scripts still use > iptables even in fedora-26. > > IIUC, iptables and nft are two different interfaces to netfilter. I > don't know if it really matters, at least for the R4.0 window. I'd > prefer to put the syntax change (for docs) off until a later release. I was recently thrown by the mix of both nftables and iptables in R4. The qubes docs don't clarify much. The qubes firewall scripts use nft. Most of the discussion on the qubes website documentation is about iptables, but there are also a few mentions of nft. The upgrade instructions (going from R3.2 to R4) did not mention converting rules from iptables to nftables. It looks like other related projects (one example is qubes-tunnel) is using iptables. Just reading a few things and trying to come up to speed, I get the impression that nftables and iptables should not both by used at the same time. Even if technically possible (i.e. both sets of rules applied correctly), it strikes me as not a great idea to maintain packet filtering rules in two different ways. What is the best practice recommendation on this (for R4, Fedora 28 template)? Are we to be using, exclusively, nftables in R4? The last I read about this (for 4.0) is that nftables is used in Fedora Qubes code, but Debian Qubes is still using iptables. That still appears to be the case since nftables is not installed in my debian-9 templates. I've submitted qubes-tunnel to Qubes with iptables commands only, with the intention to transition to nftables (or that other new interface in Linux, name escapes me just now) for Qubes 4.1. Someone who is just starting a project might be better off going with nftables. ... until yet another packet filtering mechanism replaces nftables (in that case, bpfilter [1]). I understand the rationale behind using nftables [2] but given how it is widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it wasn't worth it. The OP's post confirms there's quite some confusion about how it interacts with iptables, and the official documentation is far from helpful. I'm quite proficient with iptables and networking in general but it took me half an hour to understand how to tweak Qubes' nftables rules last time I wanted to change something in the firewall, while I would have done that task in less than one minute with iptables. I could have spent a few hours learning nftables to improve the official doc but at my age I prefer to spend time learning tech that significantly improves things (eg. Qubes OS over standard linux distribution) over loosing time learning stuff that is only marginally better. Anyway - I digress :) [1] https://old.lwn.net/Articles/747551/ [2] https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500 I'm concerned about the confusion and unnecessary complexity here. Network packet filtering is certainly (one of) those features that software such Qubes needs to be solid on (in both design approach and implementation detail). Is the Qubes team confident in the current situation, such that users of Qubes should not be concerned? nb. This is not meant to be a criticism at all. I very much appreciate the hard (and complicated) work going into Qubes. I'm just looking to understand the current situation better so as to judge whether my concern is warranted or not. As an example: I'm wanting to enable some specific network traffic between two qubes. The docs say to use iptables (https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes). qubes-firewall-user-script also specifies iptables rules. But qvm-firewall implements the rules it manages using nftables. So the firewall VMs have both iptables rules and nftables rules in effect. And these are different sets of rules. It's not that the iptables command and the nft command are just two user interfaces showing the same packet filtering rules. They are different packet filtering rules. This seems like a receipt for disaster. Is this the wrong forum for this discussion? Should this be on qubes-devel, or an issue in qubes-issues at https://github.com/QubesOS/qubes-issues/issues? You'll definitely get more visibility on qubes-devel. FWIW I'm not concerned about the complexity itself: I trust the Qubes devs not to mess up. IMHO the problem is that people proficient with iptables are not willing to spend time learning yet another packet filter tool when iptables works
Re: [qubes-users] nftables vs iptables
On 10/9/18 11:44 AM, mfreemon wrote: On 10/8/18 10:56 AM, mfreemon wrote: On 10/2/18 2:25 AM, Ivan Mitev wrote: On 10/2/18 1:32 AM, Chris Laprise wrote: On 10/01/2018 05:48 PM, mfreemon wrote: On 1/11/18 3:01 PM, Chris Laprise wrote: > On 01/10/2018 03:47 PM, Connor Page wrote: >> The official templates use nftables so shouldn’t be mixed with iptables. I didn’t have time to learn about nftables, so just removed nftables package from debian 9 template. YMMV. > > Hmmm, I was just thinking how Qubes' own guest scripts still use > iptables even in fedora-26. > > IIUC, iptables and nft are two different interfaces to netfilter. I > don't know if it really matters, at least for the R4.0 window. I'd > prefer to put the syntax change (for docs) off until a later release. I was recently thrown by the mix of both nftables and iptables in R4. The qubes docs don't clarify much. The qubes firewall scripts use nft. Most of the discussion on the qubes website documentation is about iptables, but there are also a few mentions of nft. The upgrade instructions (going from R3.2 to R4) did not mention converting rules from iptables to nftables. It looks like other related projects (one example is qubes-tunnel) is using iptables. Just reading a few things and trying to come up to speed, I get the impression that nftables and iptables should not both by used at the same time. Even if technically possible (i.e. both sets of rules applied correctly), it strikes me as not a great idea to maintain packet filtering rules in two different ways. What is the best practice recommendation on this (for R4, Fedora 28 template)? Are we to be using, exclusively, nftables in R4? The last I read about this (for 4.0) is that nftables is used in Fedora Qubes code, but Debian Qubes is still using iptables. That still appears to be the case since nftables is not installed in my debian-9 templates. I've submitted qubes-tunnel to Qubes with iptables commands only, with the intention to transition to nftables (or that other new interface in Linux, name escapes me just now) for Qubes 4.1. Someone who is just starting a project might be better off going with nftables. ... until yet another packet filtering mechanism replaces nftables (in that case, bpfilter [1]). I understand the rationale behind using nftables [2] but given how it is widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it wasn't worth it. The OP's post confirms there's quite some confusion about how it interacts with iptables, and the official documentation is far from helpful. I'm quite proficient with iptables and networking in general but it took me half an hour to understand how to tweak Qubes' nftables rules last time I wanted to change something in the firewall, while I would have done that task in less than one minute with iptables. I could have spent a few hours learning nftables to improve the official doc but at my age I prefer to spend time learning tech that significantly improves things (eg. Qubes OS over standard linux distribution) over loosing time learning stuff that is only marginally better. Anyway - I digress :) [1] https://old.lwn.net/Articles/747551/ [2] https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500 I'm concerned about the confusion and unnecessary complexity here. Network packet filtering is certainly (one of) those features that software such Qubes needs to be solid on (in both design approach and implementation detail). Is the Qubes team confident in the current situation, such that users of Qubes should not be concerned? nb. This is not meant to be a criticism at all. I very much appreciate the hard (and complicated) work going into Qubes. I'm just looking to understand the current situation better so as to judge whether my concern is warranted or not. As an example: I'm wanting to enable some specific network traffic between two qubes. The docs say to use iptables (https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes). qubes-firewall-user-script also specifies iptables rules. But qvm-firewall implements the rules it manages using nftables. So the firewall VMs have both iptables rules and nftables rules in effect. And these are different sets of rules. It's not that the iptables command and the nft command are just two user interfaces showing the same packet filtering rules. They are different packet filtering rules. This seems like a receipt for disaster. Is this the wrong forum for this discussion? Should this be on qubes-devel, or an issue in qubes-issues at https://github.com/QubesOS/qubes-issues/issues? s/receipt/recipe/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to
[qubes-users] Re: What do you guys think about the "OnlyKey"
On Friday, November 3, 2017 at 2:38:06 PM UTC-4, Fabian wrote: > A lot of people know the Yubikey, but the Yubikey has one big "problem": It > has only 2 slots for Passwords. > I thought about storing my password for my disk encryption on such a key, so > I can a) use a stronger passphrase and b) don't have to type it in every > time, especially when I am at University, ... > > So I found the "OnlyKey" which is basically a Yubikey, just far less known > and it has 12+12 Slots. > https://crp.to/p/ > > I ordered one plus a small purse which I can attach to my belt, so I always > have the key with me. > What dou you think about it - is it a good idea or am I missing something > really important? > > > Negatives are: > -Product comes from the US (Yubikey aswell) > -Setting it up is done over a Google Chrome Addon (I had a bad feeling about > it, so I just made a new VM, installed chrome, disabled the network > connection, set up the key and then deleted the VM). > > The price is okay so far (46$), in my case it nearly doubled up because of > taxes (Germany) and because I've chosen Priority Shipping from Amazon US, > instead of the standard shipping (which takes approximately 2-3 Weeks). Hi Fabian, I hoping you'll get this message. I have an OnlyKey now and cannot get it to work properly (won't type when button is touched). Have you had any luck getting it to work with Qubes OS 4.0? John -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0ca6a6e3-0af1-4c56-ac75-7d4c684cc29d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Hewlett_Packard-HP_EliteBook_2560p
Qubes 3.2 with TPM, TXT, and VT-d enabled. Function keys work out of the box. Wireless network doesn't resume properly after suspend and on wake the sys-net VM often crashes, requiring shutting down all VMs depending on network and starting them again in correct order. Otherwise very compatible and stable machine. Also boots and runs Qubes 4.0. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0f3b7c56-e800-3378-76d6-c6215ab762dc%40bpam.uk. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Hewlett_Packard-HP_EliteBook_2560p-20181009-174755.yml Description: application/yaml
Re: [qubes-users] nftables vs iptables
On 10/8/18 10:56 AM, mfreemon wrote: On 10/2/18 2:25 AM, Ivan Mitev wrote: On 10/2/18 1:32 AM, Chris Laprise wrote: On 10/01/2018 05:48 PM, mfreemon wrote: On 1/11/18 3:01 PM, Chris Laprise wrote: > On 01/10/2018 03:47 PM, Connor Page wrote: >> The official templates use nftables so shouldn’t be mixed with iptables. I didn’t have time to learn about nftables, so just removed nftables package from debian 9 template. YMMV. > > Hmmm, I was just thinking how Qubes' own guest scripts still use > iptables even in fedora-26. > > IIUC, iptables and nft are two different interfaces to netfilter. I > don't know if it really matters, at least for the R4.0 window. I'd > prefer to put the syntax change (for docs) off until a later release. I was recently thrown by the mix of both nftables and iptables in R4. The qubes docs don't clarify much. The qubes firewall scripts use nft. Most of the discussion on the qubes website documentation is about iptables, but there are also a few mentions of nft. The upgrade instructions (going from R3.2 to R4) did not mention converting rules from iptables to nftables. It looks like other related projects (one example is qubes-tunnel) is using iptables. Just reading a few things and trying to come up to speed, I get the impression that nftables and iptables should not both by used at the same time. Even if technically possible (i.e. both sets of rules applied correctly), it strikes me as not a great idea to maintain packet filtering rules in two different ways. What is the best practice recommendation on this (for R4, Fedora 28 template)? Are we to be using, exclusively, nftables in R4? The last I read about this (for 4.0) is that nftables is used in Fedora Qubes code, but Debian Qubes is still using iptables. That still appears to be the case since nftables is not installed in my debian-9 templates. I've submitted qubes-tunnel to Qubes with iptables commands only, with the intention to transition to nftables (or that other new interface in Linux, name escapes me just now) for Qubes 4.1. Someone who is just starting a project might be better off going with nftables. ... until yet another packet filtering mechanism replaces nftables (in that case, bpfilter [1]). I understand the rationale behind using nftables [2] but given how it is widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it wasn't worth it. The OP's post confirms there's quite some confusion about how it interacts with iptables, and the official documentation is far from helpful. I'm quite proficient with iptables and networking in general but it took me half an hour to understand how to tweak Qubes' nftables rules last time I wanted to change something in the firewall, while I would have done that task in less than one minute with iptables. I could have spent a few hours learning nftables to improve the official doc but at my age I prefer to spend time learning tech that significantly improves things (eg. Qubes OS over standard linux distribution) over loosing time learning stuff that is only marginally better. Anyway - I digress :) [1] https://old.lwn.net/Articles/747551/ [2] https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500 I'm concerned about the confusion and unnecessary complexity here. Network packet filtering is certainly (one of) those features that software such Qubes needs to be solid on (in both design approach and implementation detail). Is the Qubes team confident in the current situation, such that users of Qubes should not be concerned? nb. This is not meant to be a criticism at all. I very much appreciate the hard (and complicated) work going into Qubes. I'm just looking to understand the current situation better so as to judge whether my concern is warranted or not. As an example: I'm wanting to enable some specific network traffic between two qubes. The docs say to use iptables (https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes). qubes-firewall-user-script also specifies iptables rules. But qvm-firewall implements the rules it manages using nftables. So the firewall VMs have both iptables rules and nftables rules in effect. And these are different sets of rules. It's not that the iptables command and the nft command are just two user interfaces showing the same packet filtering rules. They are different packet filtering rules. This seems like a receipt for disaster. Is this the wrong forum for this discussion? Should this be on qubes-devel, or an issue in qubes-issues at https://github.com/QubesOS/qubes-issues/issues? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit
[qubes-users] Recreate boot content
I have installed Qubes 3.2 and after some usage my /boot partition gone empty. I'm dualbooting and I have been transitioning for qubes for a good reason. So my question is can I recreate the files from /boot/efi? I have tried booting the recovery mode + chroot into /mnt/sysimage. But on the chroot I had no grub2-install (qubes 3.2). Any tips are appreciated Thanks! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/09e17c61-3911-45e2-89c1-b003a1801fb7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is it possible to install Qubes OS on another Internal Hard Drive partition?
On 10/8/18 4:42 PM, mirtilloaz...@gmail.com wrote: If so, how do you do it? The only reason I can think to do so would be to boot Qubes as an alternative OS, so I am guessing what you need is a multi-boot configuration. You can read about that here: Multibooting Qubes https://www.qubes-os.org/doc/multiboot/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/25b669e7-708d-a6ce-0c2f-3e2cdda617b5%40jhuapl.edu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes and Mega Cloud App using
On 10/9/18 11:39 AM, myblackcatisb...@gmail.com wrote: Hello guys, Since the Windows 7 HVM machine unfortunately does not recognize any external drives, I was forced to upload my documents to the Mega Cloud. Qubes Windows Tools [1] allow you to copy files from/to a Windows VM to linux VMs. You could for instance mount your external disk in sys-usb and copy files to your windows VM from there. Wouldn't it be easier than downloading from Mega cloud ? [1] https://www.qubes-os.org/doc/windows/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/081a6572-8378-bdf9-2854-1ab7d75bcae8%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Networking between qubes and HVMs
I am still having difficulty getting these vms to be reachable with each other. Basically what I want to do is have a home security/automation vm, and a freenas vm, communicate with the outside world and with the vm that controls my access points/physical switches. Currently I have the usual sys-net/sys-firewall. Each service vm(access points, freenas, etc.) Has its own firewall vm. Those fireall service vms are all connected to sys-firewall. I followed the instructions in the qubes-firewall docs setting up forwarding between the service firewalls to travel through sys-firewall. And each service firewall vm(and their associated service vm), can ping every firewall vm in the system. But the actual service vms themselves cannot ping each other. So for example: freenas vm > freenas vm firewall > sys firewall > home security firewall vm. All will allow ping, but i cant get freenas to talk to home security vm, as i intend on using the nas storage to store the camera footage. Similarly the home security vm can do the same amount of pings, but fails to talk to freenas. I suspect NAT is the issue but lack the knowledge base to enable this to work. I am not particularly dead set on using all these firewall vms either but this is the config thats gotten me the furthest so far. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/78a21e71-1e3a-44ef-8afd-593987b20b01%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes and Mega Cloud App using
On Tuesday, October 9, 2018 at 4:39:54 AM UTC-4, myblackc...@gmail.com wrote: > Hello guys, > > Since the Windows 7 HVM machine unfortunately does not recognize any external > drives, I was forced to upload my documents to the Mega Cloud. > > Unfortunately, I always get a script error when downloading files, or that > the Firefox capacities are insufficient. I have already increased the > execution of the script in Firefox and have reset the default settings of the > browser back to the default settings. > > How can I download the Mega Cloud App under Qubes? > Has anyone else a tip on how I can easily download larger files> 2GB with > Firefox? > > I'm glad about help and your feedbacks. Is it possible that the script/extension uses temporary space on a volume that doesn't have enough storage in it? Open a terminal in the qube/vm that you attempting the download in and use the watch command to see if any of the volumes are getting full: watch df If a volume appears to be getting maxed out (or perhaps over 50% if the script/extension has to double buffer), then increase the size of the volume in the qube/vm's settings. -brendan -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/14b4d2cc-e86e-4780-b37b-2201c28beae4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes and Mega Cloud App using
Hello guys, Since the Windows 7 HVM machine unfortunately does not recognize any external drives, I was forced to upload my documents to the Mega Cloud. Unfortunately, I always get a script error when downloading files, or that the Firefox capacities are insufficient. I have already increased the execution of the script in Firefox and have reset the default settings of the browser back to the default settings. How can I download the Mega Cloud App under Qubes? Has anyone else a tip on how I can easily download larger files> 2GB with Firefox? I'm glad about help and your feedbacks. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e84b5715-eaa4-4f03-a126-66a7b8fe978b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
