uxora-com

It still works for me, I think it is something to do with your macvlan directly connected to the vswitch instead of a ethX interface. Well it does not work - posix acl does not seem to be compiled in 9p modules, even if it works it is not use by dsm which use proprietary syno_acl compile in their fs - xattr seems to works but it's not use by dsm - Dsm office seems to be based on synoacl (for security and share management) and cannot work without it So there is nothing much to do about that. HTH,

Can you provide me your "Docker run" command line and your "9p mount" command line ... and I may give a try to see if dsm ACL works with 9p.

UPDATE of xpenology-docker: - Instead of using BOOTLOADER_URL, you can now pass local bootloader file with: "-v /local_path/synoboot.tgz:/bootloader" - Add BOOTLOADER_FORCE_REPLACE variable to replace existing bootloader in DISK_PATH Well, let me know if something does not work. Enjoy. HTH,

UPDATE of xpenology-docker: - DHCP is now available (Check README for more information) - Now works without "--privileged" docker option for more security # On docker host # Create a macvlan matching your local network $ docker network create -d macvlan \ --subnet=192.168.0.0/24 \ --gateway=192.168.0.1 \ --ip-range=192.168.0.100/28 \ -o parent=eth0 \ macvlan0 # Run xpenology docker (Warning: --device-cgroup-rule number may be different for you) $ docker run --name="xpenodock" --hostname="xpenodock" \ --cap-add=NET_ADMIN --device-cgroup-rule='c 235:* rwm' \ --device=/dev/net/tun --device=/dev/kvm --device=/dev/vhost-net \ --network macvlan0 -e VM_NET_DHCP="Y" \ -e BOOTLOADER_URL="http://myurl/synoboot.tgz" \ -e RAM="512" -e DISK_SIZE="16G" \ -e GRUBCFG_SN="1234ABC012345" \ -e GRUBCFG_SATAPORTMAP="6" -e GRUBCFG_DISKIDXMAP="00" \ -e DISK_PATH="/xpy/diskvm" -e VM_9P_PATH="/xpy/share9p" \ -v /host_dir/kvm:/xpy/diskvm -v /host_dir/data:/xpy/share9p \ uxora/xpenology HTH,

Just to let you know that I have updated my xpenology on docker for redpill loader compatibility (and still works with jun's loader). I have tested it against DS3615xs bootloaders and it seems to works pretty well. This is not mean to be used as a production system but it's pretty good for testing things and fast to deploy with an docker image of 67MB only. For example: - You can quickly test your newly build bootloader - You can test an ugrade or another risky thing ... by doing a snapshot before and if everything goes wrong, restore the snapshot or destroy container - Etc. Quickly deploy as follow (check github for more options): # On docker host # Create a macvlan matching your local network $ docker network create -d macvlan \ --subnet=192.168.0.0/24 \ --gateway=192.168.0.1 \ -o parent=eth0 \ macvlan0 # Run xpenology docker with ip 192.168.0.50 $ docker run --name="xpenodock" --hostname="xpenodock"\ --privileged --cap-add=NET_ADMIN \ --device=/dev/net/tun --device=/dev/kvm \ --network macvlan0 --ip=192.168.0.50 \ -e BOOTLOADER_URL="http://myurl/synoboot.tgz" \ -e GRUBCFG_SN="1234ABC012345" \ -e GRUBCFG_DISKIDXMAP="00" -e GRUBCFG_SATAPORTMAP="2" \ -v /host_dir/kvm:/xpy/diskvm \ uxora/xpenology Open web on 192.168.0.50:5000 and enjoy! # Some snapshot commands $ docker exec xpenodock vm-snap-create SnapB4Upd $ docker exec xpenodock vm-snap-restore SnapB4Upd $ docker exec xpenodock vm-snap-delete SnapB4Upd # Poweroff $ docker exec xpenodock vm-power-down Source: - https://github.com/uxora-com/xpenology-docker -

Indeed ... good luck then.

If you can ping it, then it should work as long as you use the right port to access it and this is not block by any firewall! (sometimes I'm not sure you even tried to find a solution before posting ... and again, as i said in my last post, you don't need port mapping option "-p" no more ... and you should find your solution.) Well, what you need to know is that I already made it working ... and this is already a big thing to know ... so it should work for u as well normally! 9p seems to have posix acl abilities ... but i don't know if modules has been compile with this option and even if it does, I not sure it will still works with dsm ACL. You need to try and test and if it succeed to make it working let us know. Otherwise you have other fs option like SMB/CIFS or NFS. HTH,

The answer is on my last post about that:

What is the step to reproduce this issue? I did hundred of restart of the same containers without any issue.

No, I never get this issue ... maybe this is something to do with trying to 9p fs mountpoint /xpy_syst folder. (I should remove this in my README example). You can try to different VM_9P_OPTS and mount option to see if ACL works with xpenology. Maybe you want your xpenology to be more expose by setting it its own fixed IP. You can do it by creating a macvlan then add "--network MyMacvlanName --ip=192.168.x.x" (then i wont need -p option no more) Check this : https://docs.docker.com/network/network-tutorial-macvlan/ HTH,

I just did some test and i did have some issue of editing a file with FileEditor and it cannot save the change. This 9p folder is not configure to use dsm ACL permission, but use the basic linux filesystem permission. I just run these commands in ssh to fix this: $ sudo chown -R root:users /volume1/datashare9p $ sudo chmod -R g+w /volume1/datashare9p And it may depends on your qemu and mount option as well, you may want to check this about that (especially "access" option) : https://wiki.qemu.org/Documentation/9psetup I didn't really play and try to optimize qemu and mounting options about 9pfs, I just get and keep the same command from an older project. I just see that it works and never check its reliability and speed performance. HTH,

Actually if it's just to change the mount point, you don't need to delete bootloader ... you can just recreate a new container with the same options but just changing mount point option (-v). The instruction with delete, I gave you, is if you want to change an option about the bootloader ... otherwise you just need to recreate the container without any delete (except the old container if you want). Don't worry about that, you should get back your dsm xpenology with all your data in place even in a new container as long as it uses the same vm disks.

Congratulation! For smb, you need to port forward smb port on docker with option: "-p 137-139:137-139 -p 445:445". Then you can access smb with its IP (ie. "\\192.168.0.10"). If you want to name it, you can add it to hosts file on your windows/linux. (Needs administrator privileges) Not sure how to change option (-e and -v) of an existing container ... it was possible in old docker version, maybe it still possible ... well, I will let u find it in google, and let us know if u find it. Otherwise as alternative, you can recreate a new container with new options (with keeping vm disks) as follow : - In "syst/" folder, uncompress : "$ "tar -xzf bootloader.img.tar.gz" - Delete (or move it): "$ rm bootloader.img.tar.gz bootloader.qcow2" - Delete (if you want): "$ docker container rm $( docker container ls -qf 'ancestor=uxora/xpenology' )" - Then recreate a container with new option: "$ docker run --privileged [...]" And about automount 9p at boot time, use "Control Panel > Task Scheduler > Create > Triggered Task" to run your command line as root. HTH,

Here it is, I just pushed modification on github and docker server. You can now add the following option to docker command line: -e GRUBCFG_DISKIDXMAP="00" -e GRUBCFG_SATAPORTMAP="1" This should fix your disk sata error. About your your iptables thing, I don't know if it's fixed because I cannot test it (and i dont want it your cp/mv stuff coz it break in other system) but let me know.

Ok, I think I figured it out. It's something about the bootloader which has set DiskIdxMap and SataPortMap values too high that xpenology-docker does not seem to like. There is GRUBCFG_DISKIDXMAP and GRUBCFG_SATAPORTMAP variable to fix that ... but it does not seems functional with the way how it changes the value in bootloader, I will fix that later with iptables stuff.