| rrq | beagleburt: note that nz.deb.devuan.org is the one "country code" currently available, resolving to the NZ mirror (only). afaik it has good uptime and is usually quite fast also to here (AU), but by the looks of it, it's "refresh cycle" is at least 12 hours | 00:13 |
|---|---|---|
| miles | Hello: looking for guidance on kde/audio/backend setup on Beowulf. Low volume, no active devices visible in widget control, etc. Anyone willing to point me at the right info? | 00:21 |
| systemdlete2 | I'm trying to use fuse-overlayfs and it appears to set the uid/gid as I want it, but when I try to create a file in one of the directories there, I get an error saying it is not permitted. | 09:44 |
| systemdlete2 | Am I supposed to create a new user namespace before using overlayfs, or does the system just assume the default (I'm guessing I am already in a default namespace already, but idk) | 09:45 |
| systemdlete2 | The one lousy (and boy do I mean lousy) man page I found for fuse-overlayfs does not mention anything about having to do so, but it does reference the user_namespace man page. | 09:46 |
| systemdlete2 | That page, btw, does not explain the syntax, and has formatting issues to boot. | 09:46 |
| systemdlete2 | The exact error is "Operation not permitted" | 09:48 |
| systemdlete2 | Both the "lower" and "upper" filesystems are local to the system. | 09:48 |
| systemdlete2 | the call to user-overlayfs succeeds with no errors. Listing perms and ownership on files in the overlay fs are mapped correctly to my user id/gid | 09:50 |
| systemdlete2 | I'm using the stock beowulf kernel (4.19.0) | 10:08 |
| gnarface | no experience with it, but don't you need space in ram for the differences between the two filesystems? is it possible the permission thing is a red herring/ | 10:45 |
| gnarface | ? | 10:45 |
| rrq | systemdlete2: this is not the built-in overlay? (man mount; search "Mount options for overlay") | 11:14 |
| gour | hiya, now i'm fully (with both machines) on devuan - migrated from debian/sid to ceres/runit :-) | 13:59 |
| gour | great job and congrats to all the devs! | 14:00 |
| brocashelm | nice, i'm also on ceres/runit for a whole year so far. runit is being actively worked on for devuan | 14:04 |
| brocashelm | check out this thread if you haven't: https://dev1galaxy.org/viewtopic.php?id=3716 | 14:06 |
| brocashelm | anyone is welcome to contribute their script conversions | 14:06 |
| gour | brocashelm: heh, i'm glad i've picked the right one ;) | 14:08 |
| brocashelm | gour: ya, it's a lot faster/lighter and i have had less crashes with it compared to sysvinit. only problem is a lot of services still use sysv scripts, but the devs are working to converting as many as possible to runsv | 14:13 |
| gour | brocashelm: so far, i'm good, but still restoring many stuff from the backup..will see if something is missing | 14:34 |
| systemdlete2 | gnarface: The requirement, afaik from the docs, is that you supply a "work" directory, which I am already doing. I think it is that work directory that you are referring to, and it has to be on the same filesystem as the overlay. | 16:11 |
| systemdlete2 | rrq: No, this is the fuse version, which I think might ultimately use the built-in one. But I am not sure. | 16:12 |
| systemdlete2 | rrq: I looked for the built-in one, but did not find it. I tried passing -t overlayfs to mount, but it didn't work. So I ended up using the fuser version, which is actually more convenient because it doesn't require root priv | 16:13 |
| systemdlete2 | I'm wondering if the lowerdir and upperdir cannot be on the same fs, which is how mine is setup currently. | 16:14 |
| fsmithred | systemdlete2, they can be on the same fs | 16:22 |
| fsmithred | all of them can. I played with the kernel version this morning. | 16:23 |
| systemdlete2 | fsmithred: I thought so but wasn't sure. | 16:23 |
| fsmithred | mount -t overlay overlay -olowerdir=something,upperdir=other,workder=yetanother /some-mountpoint | 16:24 |
| systemdlete2 | funny part is that I was able to use fuse-overlay yesterday. Sadly, I made a mistake in invocation originally and had to reboot because I couldn't unmount it. | 16:24 |
| fsmithred | check your command history | 16:24 |
| systemdlete2 | After rebooting, it worked. But that was just a sort of test scenario; I was trying it out to see how it works. | 16:24 |
| systemdlete2 | Oh, I know exactly what I did wrong. Typo. I specified the same upper and target dirs | 16:25 |
| systemdlete2 | It should not have allowed that! | 16:25 |
| systemdlete2 | but a reboot cleared that out. | 16:25 |
| fsmithred | I took a debootstrapped beowulf base, overlayed another dir and chrooted to install graphical apps | 16:25 |
| fsmithred | so they are separate layers | 16:26 |
| fsmithred | it works, it's pretty cool | 16:26 |
| systemdlete2 | When mine was working, it really was cool. I agree. | 16:26 |
| systemdlete2 | Did exactly what I wanted/expected. | 16:26 |
| systemdlete2 | But once I set up a slightly different scenario, it is being a pest. | 16:27 |
| systemdlete2 | Maybe I should try rebooting again. | 16:27 |
| systemdlete2 | I would not think that is necessary, but idk. | 16:27 |
| fsmithred | you know 'umount -l' right? | 16:27 |
| systemdlete2 | for fuse, you have to use fusemount, not umount | 16:28 |
| fsmithred | oh yeah | 16:28 |
| systemdlete2 | and the mount requires a different tool also | 16:28 |
| systemdlete2 | but the concept is the same. | 16:28 |
| fsmithred | doesn't that also have a lazy option? | 16:28 |
| systemdlete2 | not sure | 16:28 |
| fsmithred | yeah -z | 16:28 |
| systemdlete2 | fuser-overlayfs does not seem to have a -z option | 16:29 |
| fsmithred | fusermount does | 16:29 |
| fsmithred | use -z instead of -u | 16:29 |
| systemdlete2 | oh, the unmount, yes. | 16:30 |
| systemdlete2 | I can unmount the fuse filesystem... now. When I had mounted it incorrectly, it was giving me grief. | 16:30 |
| systemdlete2 | Again, it should not have permitted me to do what I did in the first place. I'm certain that is just a bug. | 16:31 |
| fsmithred | oh, in that case, you should probably do it again | 16:31 |
| systemdlete2 | do what again? reboot? | 16:31 |
| fsmithred | no | 16:31 |
| fsmithred | screw up | 16:32 |
| systemdlete2 | oh | 16:32 |
| fsmithred | make sure you can do it reliably | 16:32 |
| fsmithred | then report the bug | 16:32 |
| systemdlete2 | yes... but later. | 16:32 |
| fsmithred | or see if someone else knows about it already | 16:32 |
| systemdlete2 | for now, I just want to get this working for me! | 16:32 |
| systemdlete2 | (I promise I WILL investigate and report it if it is reproducible) | 16:32 |
| systemdlete2 | fsmithred: Since the last boot, have you been able to use the overlayfs? If so, can you try to tear it down and change it slightly so it mounts the target somewhere else instead? That was what I changed. | 16:34 |
| systemdlete2 | without an intervening reboot I mean | 16:34 |
| fsmithred | just change my mountpoint? | 16:34 |
| systemdlete2 | yes | 16:34 |
| fsmithred | probably | 16:34 |
| systemdlete2 | somewhere on the same fs | 16:34 |
| fsmithred | I did two tests in different locations | 16:34 |
| fsmithred | no reboot | 16:34 |
| systemdlete2 | hmmm | 16:34 |
| fsmithred | gimme a minute | 16:34 |
| systemdlete2 | so that might not be the issue then... but thanks for looking into it and trying | 16:34 |
| systemdlete2 | Also, change the lowerdir | 16:35 |
| systemdlete2 | When my upper, lower, work, and target were in the same superdirectory, it worked. Not sure that is the issue, but it did work. | 16:35 |
| fsmithred | ok | 16:36 |
| fsmithred | will try | 16:36 |
| systemdlete2 | thanks | 16:36 |
| systemdlete2 | what did you have to do to use the regular overlayfs (not fuse)? I tried it, as you stated above, but mount complained it did not know any overlayfs | 16:37 |
| systemdlete2 | for fuse, I had to install fuse-overlayfs package. | 16:38 |
| fsmithred | should be in the kernel, I think | 16:39 |
| systemdlete2 | OK, using the built-in, non-fuse approach, I run: mount -t overlay -o lowerdir=lower,upperdir=upper,work=work target | 16:42 |
| systemdlete2 | it errors with: mount: target: can't find in /etc/fstab. | 16:43 |
| systemdlete2 | (I've created all 4 directories in a testing area under root's home) | 16:43 |
| systemdlete2 | I'm doing something wrong here, I'm sure. | 16:43 |
| fsmithred | it works | 16:44 |
| fsmithred | overlay overlay | 16:44 |
| systemdlete2 | What is the problem with my invocation then? | 16:45 |
| * ShorTie wonders Gentoo ?? | 16:45 | |
| fsmithred | you are missing "overlay" | 16:45 |
| systemdlete2 | where? | 16:45 |
| fsmithred | say it twice | 16:45 |
| fsmithred | mount -t overlay overlay ... | 16:45 |
| systemdlete2 | mount -t overlay overlay -o lowerdir=lower,upperdir=upper,work=work target ? | 16:46 |
| systemdlete2 | I get error: mount: /root/tmp/target: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error | 16:47 |
| fsmithred | your command looks right | 16:47 |
| systemdlete2 | oops. | 16:47 |
| systemdlete2 | workdir=, not work= !!! (duh!) | 16:48 |
| fsmithred | oh | 16:48 |
| systemdlete2 | let me check to see if I made the same booboo in fuse version... | 16:48 |
| systemdlete2 | no... it's right (workdir=) in my fuse invocation. | 16:48 |
| systemdlete2 | In my case, though, the lowerdir is deep under /var | 16:50 |
| systemdlete2 | everything else (upper, work, and target) are on one filesystem (not /var) | 16:50 |
| fsmithred | does your user have permission there? | 16:50 |
| systemdlete2 | I used mappings, and ls -l does show it is the owner | 16:50 |
| fsmithred | back in 10 | 16:50 |
| systemdlete2 | ok | 16:50 |
| systemdlete2 | My call is as follows: | 16:51 |
| systemdlete2 | fuse-overlayfs -o lowerdir=/var/local/myprog -o upperdir=upperdir -o workdir=workdir -o uidmapping=0:1000:1 -o gidmapping=0:1000:1 path/to/mountpoint | 16:52 |
| systemdlete2 | the path/to/mountpoint is on the same fs with upperdir and workdir (the latter 2 being in one directory together) | 16:53 |
| systemdlete2 | when I run "ls -l" in the /path/to/mountpoint directory, it shows that files are owned by my test user, not root (whereas the lower directory, under /var, is of course owned by root) | 16:54 |
| systemdlete2 | but if I try to do something like "echo xyz > /path/to/mountpoint/newfile" it errors saying "Operation not permitted" | 16:54 |
| systemdlete2 | no wait. Now I get a different error; Permission denied. but that is just as odd | 16:56 |
| systemdlete2 | hmmm. | 16:57 |
| systemdlete2 | ownership is not my user:user, but nobody:nogroup, which I'd expect for a NFS file system, not a local one. | 16:57 |
| systemdlete2 | So I have done yet something else differently. | 16:57 |
| * systemdlete2 goes back and traces his steps carefully. | 16:57 | |
| fsmithred | nfs might be the problem | 16:58 |
| systemdlete2 | I am not using any nfs here though | 16:58 |
| fsmithred | oh, ok | 16:59 |
| systemdlete2 | both filesystems, /var and my upper and work directories are all local fs | 16:59 |
| fsmithred | and user owns the subdir in /var recursively? | 17:00 |
| systemdlete2 | no, root does | 17:01 |
| systemdlete2 | my overlay specifies uid:gid mappings | 17:01 |
| systemdlete2 | (see above) | 17:01 |
| fsmithred | you're doing this as root now? I'm lost. | 17:01 |
| systemdlete2 | no, fuse is available to nonroot users | 17:02 |
| systemdlete2 | I am doing this as my test user | 17:02 |
| fsmithred | so shouldn't test user own that dir? | 17:02 |
| systemdlete2 | the problem/difference may just be something in the fuse implementation | 17:02 |
| systemdlete2 | which dir? Not the one under /var. Those are system directories and files that would not be owned by a regular user | 17:03 |
| systemdlete2 | test user owns all the other directories though. In the merged (mounted) image, which I have been calling "target", the files appear to be owned by the test user due to the mappings I specified | 17:04 |
| fsmithred | yeah, ok. That makes sense. I can mount system dirs with sshfs | 17:05 |
| systemdlete2 | I am really wondering if it would make sense to reboot. I am thinking, what if the first mount, which worked for me, has left some artifacts in the driver's memory, or something else screwy in fuse. I've run into some fuse issues in the past with other tools. | 17:08 |
| fsmithred | lsof might help with that | 17:09 |
| systemdlete2 | I'm trying rmmod fuse and see if that clears it | 17:09 |
| systemdlete2 | I think I see part of the issue. I was not aware of this. The actual mountpoint directory, after the mount, shows nobody:nogroup. I definitely cannot write there. But the subdirectories are correctly mapped as I specified. | 17:13 |
| fsmithred | mountpoint inherits permissions from the mounted volume | 17:14 |
| systemdlete2 | However, I cannot write in those subdirs even though I have permissions there. | 17:14 |
| systemdlete2 | I don't care if I can't write to the mountpoint directory. I don't need to. | 17:14 |
| systemdlete2 | that is why I was getting a different error. No, I still get the "operation not permitted" error when I try to create a new file in one of the subdirectoreis | 17:15 |
| systemdlete2 | *subdirectories | 17:15 |
| fsmithred | subdirs where? | 17:16 |
| systemdlete2 | which is where I need write access, and the whole point to this entire exercise. | 17:16 |
| systemdlete2 | under the mountpoint | 17:16 |
| systemdlete2 | I mean, on the mounted fs, not lowerdir | 17:16 |
| fsmithred | the mountpoint is where they are merged, right? | 17:17 |
| systemdlete2 | that's what I mean, yes | 17:17 |
| fsmithred | isn't that where you're working? | 17:17 |
| systemdlete2 | where I am trying to work | 17:17 |
| fsmithred | ok | 17:17 |
| systemdlete2 | let me explain what I am doing, ok? | 17:17 |
| fsmithred | yeah, you should be able to write ot it, and anything you do should stay on the upper dir when you unmount it all | 17:17 |
| systemdlete2 | I have a program that saves files under /var/local/... | 17:18 |
| systemdlete2 | When I want to test my program, I have set up an area somewhere else from the "live" program. But I need a recent set of test data. What better data than what the live program has been saving? OK, but... | 17:19 |
| systemdlete2 | the program will generate new data files. So I don't want to clobber the live data in case any changes I've made to the test version of the program causes damage. | 17:19 |
| fsmithred | makes sense | 17:20 |
| systemdlete2 | And, besides, the data under /var should be kept pristine anyway. And those files are owned by root anyway. | 17:20 |
| systemdlete2 | I do all of my testing using my test/development user. | 17:20 |
| systemdlete2 | Now, it occurs to me I could probably use a root jail instead of doing it this way. | 17:21 |
| systemdlete2 | Or maybe a container or the like. | 17:21 |
| systemdlete2 | But this seemed like a lightweight approach. | 17:21 |
| systemdlete2 | And it almost works... | 17:21 |
| systemdlete2 | I can read files, but I can't write to them or create new ones. | 17:23 |
| systemdlete2 | Obviously, the directories are not really owned by my test user, but the fuse driver should be making them act that way semantically. That's its purpose for overlayfs. | 17:24 |
| systemdlete2 | I think I will try rebooting and see if it will work in a fresh environment. | 17:24 |
| systemdlete2 | fsmithred: Thanks for the help today (again...) | 17:25 |
| fsmithred | yw | 17:25 |
| systemdlete2 | bbl | 17:25 |
| systemdlete2 | fsmithred: This is one of the biggest "duh" moments of my life... | 17:43 |
| systemdlete2 | It's not the inheritance of the permissions that is a problem here. | 17:43 |
| systemdlete2 | It's the permissions themselves!!! | 17:43 |
| systemdlete2 | The error is correct; the operation should NOT be permitted. I forgot that the files in lowerdir are not readable by regular users anyway. | 17:44 |
| systemdlete2 | So they cannot be readable or writable by a regular user, even if uid/gid is mapped. | 17:44 |
| systemdlete2 | So this approach is clearly not going to work for me. | 17:44 |
| systemdlete2 | It would be a clever way to raise privileges if the system did allow it. Thank goodness it does not allow it!!! | 17:45 |
| systemdlete2 | I think I'll stick with a simple cp... | 17:46 |
| systemdlete2 | (by root I mean) and then chown the files | 17:46 |
| systemdlete2 | I suppose group perms in those directories might be useful. I could add my test user to a special gruop that is allowed to peruse those files. | 17:47 |
| fsmithred | move that dir and make a new one for the tests? | 17:47 |
| fsmithred | will the program freak out if the whole data dir is replaced? | 17:48 |
| systemdlete2 | No, because root does run the program in cron | 17:48 |
| systemdlete2 | I think I'll try a group and include my test user in it. That should work fine with overlayfs, even in fuse. | 17:48 |
| fsmithred | yeah, that should work | 17:48 |
| systemdlete2 | Sorry to have bugged you with all this. I'm sure you have more important things to do. | 17:49 |
| fsmithred | although I've run into situations where root can't do anything with a volume that user mounted (sshfs) | 17:49 |
| systemdlete2 | yes, I have also. Same thing. | 17:49 |
| fsmithred | I don't remember the exact circumstances, but I remember being surprised that root wasn't allowed | 17:50 |
| systemdlete2 | I use xigmanas to store some data. When I mount it to certain systems, root cannot look at the mounted files and directories, but a regular user can. | 17:50 |
| systemdlete2 | it surprises me also | 17:50 |
| fsmithred | I need food. brb | 17:51 |
| systemdlete2 | root won't be accessing my fuse fs. It will continue to use the lowerdir. | 17:51 |
| systemdlete2 | tyt | 17:51 |
| systemdlete2 | kernel.unprivileged_userns_clone must be set to 1 ??? | 18:17 |
| systemdlete2 | (mine is 0 currently) | 18:17 |
| systemdlete2 | looks like it is not recommended to set it; can open up severe vulnerabilities | 18:20 |
| systemdlete2 | of course, I am behind about 5 firewalls and I doubt there is much internet exposure (other than firefox maybe) | 18:21 |
| systemdlete2 | This might explain why using the overlay mount option works but the fuse implementation doesn't (at least when the kernel var is not set) | 18:22 |
| systemdlete2 | group did not work as planned either. I ended up writing a (whopping) 2-liner that copies and chowns the files. I have tested it and it works fine. | 18:40 |
| systemdlete2 | Sometimes, what seems simple to do is actually far more complicated than was needed in the first place. | 18:40 |
| systemdlete2 | thanks again for all your help fsmithred | 18:41 |
| hook54321 | golinux: it looks like it's still blocked. is there someone i should talk to or a delay i should use? | 22:37 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!