Le mardi 27 février 2018 17:37:53 UTC+2, Alex Dubois a écrit : > On Tuesday, 27 February 2018 10:39:06 UTC, Yuraeitha wrote: > > On Tuesday, February 27, 2018 at 7:00:46 AM UTC+1, ThierryIT wrote: > > > Le mardi 27 février 2018 02:50:05 UTC+2, Yuraeitha a écrit : > > > > On Monday, February 26, 2018 at 8:04:44 PM UTC+1, ThierryIT wrote: > > > > > Hi, > > > > > > > > > > I would like to backup few of my VMs. > > > > > I have mount my external usb (not using sys-usb) HDD. > > > > > From the console where my HDD is attached/mounted, I have access > > > > > through /mnt/removable to all my previous (3.2) backup files. > > > > > I have created, in /mnt/removable, a new folder. > > > > > When running the Qubes backup, and choosing the newly created folder, > > > > > I have this error: > > > > > > > > > > Selected directory do not exists or not a directory > > > > > > > > > > I have created others folders, I have change permissions ... Same > > > > > problem. > > > > > Today all my folders are: > > > > > > > > > > - drwxrwxr-x 3 user:user AppVM_bck > > > > > > > > > > Same pb if root:root > > > > > > > > > > ?? > > > > > > > > Apologies, I overlooked the "- drwxrwxr-x 3 user:user AppVM_bck" line > > > > in your post. Since your USB controller then must be directly passed > > > > into the AppVM, you can try create a direct path copy directly in dom0, > > > > even though you won't be using this path. As suggested in Rusty Bird's > > > > link. Does it work for you? > > > > > > I have created the "/mnt/removable" in dom0. > > > If using as path: /mnt/removable/AppVM_bck I do still have the same error > > > message. > > > If using as path: /mnt/removable I do have a permission denied. > > > > > > drwxr-xr-x root root mnt > > > drwxr-xr-x root root removable > > > drwxrwxr-x user user AppVM_bck > > > > > > Are the permissions correct ? It should be root:root or user:user ? > > > > > > Thx > > > > It looks like you did the permissions correctly, lets try something else. I > > suggest you try make a new fixed artificial mounting path rather than the > > dynamic allocated one, because it may quite reasonably be why Qubes 4 can't > > find its way to the path when special symbolic location letters are used as > > path shortcuts, such as $HOME/ or ~/ and similar for /home/user, which > > seems similar to /run/removable. So it may be that dynamic folders aren't > > working very well. > > > > For example XFCE4 keybinding a script located in /home/user/ can be a huge > > hassle if using $HOME/ or ~/ to bypass dynamic user-names in different > > Linux systems, and instead one has to write the actual user-name in the > > path, which means it only works if using the full path name, rather than > > path shortcuts. Maybe it's the same that happens with /mnt/removable. In > > which case, it may be useful to abandon this location to something not > > bound by location rules, which can be anywhere but the official places. > > > > Perhaps this bug could even be related to the recent $ some days back? I > > dunno though, but without any insight, it seems like it maybe could be. > > > > So try un-mount the USB drive in the AppVM, and make a new fixed location > > folder, it could be in /mnt/some-folder <--- give folder a name, but > > without spaces and special letters to avoid issues. > > > > Change the some-older's ownership to user and give it permissions. Then > > once that is done, mount your drive to the folder with appropriate mounting > > permissions. Then do the same new path in dom0, with same > > ownership/permissions. > > > > Generally only the last folder should have the same permission, at least as > > far as I know the parent folder permission shouldn't matter much. So don't > > worry about the parent folders, just focus on the final folder in the path. > > > > Does it make a difference when you clear out dynamic paths for fixed paths, > > then remount it, and ensure all permissions are in place? > > > > Also I don't think you need the dom0 trick if you try this approach, > > although I could be wrong. I think the dom0 identical path trick is a > > method to trick the system to not fail on the shortcut path. So by avoiding > > shortcut paths altogether, you may not need to do the dom0 trick to bypass > > the bug. I'm not 100% sure if this how it actually works, but it may be > > worth a try. > > fyi, I had same problem, and doing the back-up at the root of the mount point > allowed me to continue (/media on a DispVM in my case where I had bound a > second HD on my SATA temporarilly).
I have tried at the mounting point too "/mnt" without succes -- 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/e66ffe66-dfeb-4491-9e9e-842577c4edf5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
