1. You should be able to reconfigure which card is enabled and how they're used in the Network section under Interfaces.
2. I would make sure that the speed is not related to your WiFi and it really depends on your hardware. Crappy hard drives will be crappy, etc.
3. Linux does not support HFS+ by default. You'll need to do some pretty exciting hackery to get it working http://askubuntu.com/questions…untu-without-access-to-os. I don't know if it'll work with OMV's GUI though.
4. Are you running OMV in a VM? A VM in OMV? I tend to run VMs bridged so they appear as machines on the LAN rather than having to deal with individual port forwarding on the host.
Posts by ikogan
-
-
So, you would need to set your permissions on the server. The fun thing about NFS is that it doesn't really do any ID mapping by default. So the UID your user(s) have on your NAS have to match the UID your user(s) have on your laptop. I'm not sure if there's a way to perform UID mapping with NFS. In addition, NFS does not do any kind of encryption or server authorization by default so it's pretty trivial for someone to connect to the NAS as your user and see your files simply by having a machine on the network that has a user with the same UID as the one on your NAS. If you don't have "root_squash" on, it gets even worse.
If you're running Ubuntu, I'd recommend using SSHFS instead. You should just be able to use the "Connect to Server" menu item and type "ssh://${username}@192.168.10.27". If you want to mount it like you are now, look into https://help.ubuntu.com/community/SSHFS. I typically use NFS for server to server communication only, and even then, with Kerberos.
-
So what is the status of the raid (cat /proc/mdstat)? Does it list a raid? If it does, you can try to assemble it first, then delete it from the web GUI. If you want to just destroy it, you can do that by wiping the first few sectors of the drive. The first trick is to get OMV's web GUI to not see it as part of the raid and I would imagine that depends on what /proc/mdstat says. You can also `grep md127 /etc/openmedivault/config.xml` to see what OpenMediaVault is configured with.
-
Great! I'm glad it worked!
-
In terms of permissions, that directory listed in the error needs to be writable by the "debian-transmission" user.
-
I'm not sure what's causing your bond0 to show up. It's possible that for there to be a bond1 there must be a bond0, so it creates one for that reason? Perhaps try deleting bond1 first, reboot, and then see what you get?
-
This may not be a concern for @Moheemo but the ACL window doesn't seem to show up for ZFS filesystems for some reason so I can't look at it. Does it support default ACLs?
-
run "grep -R bond /etc" and see what shows up in there. Here's what I get:
Code
Display Moreroot@ezra:/etc# grep -r bond * collectd/collectd.conf: Interface "bond0" network/interfaces:# bond0 network interface network/interfaces:auto bond0 network/interfaces:iface bond0 inet static network/interfaces: bond-xmit_hash_policy layer3+4 network/interfaces: bond-slaves eth0 eth1 network/interfaces: bond-mode 2 network/interfaces: bond-miimon 100 network/interfaces: bond-downdelay 200 network/interfaces: bond-updelay 200 network/interfaces:iface bond0 inet6 manual network/if-up.d/ifenslave: # $1 = basename of the file in bonding/ to write to. network/if-up.d/ifenslave: echo "$2" > "/sys/class/net/$IFACE/master/bonding/$1" network/if-up.d/ifenslave:# If the stanza bond-give-a-chance is set for a slave interface, network/if-up.d/ifenslave:# This stanza is designed to workaround a bug in wpa_supplicant, when used with bonding : network/if-up.d/ifenslave:# wpa_supplicant expect wifi authentication packets on the bond interface, but also send wifi authentication packets on the bond interface. network/if-up.d/ifenslave:# "bond-give-a-chance 10" will set the wifi interface as the primary interface for 10 seconds, then restore the previous primary interface. network/if-up.d/ifenslave: read primary < "/sys/class/net/$IFACE/master/bonding/primary" network/if-pre-up.d/ifenslave: # Return if $BOND_MASTER is already a bonding interface. network/if-pre-up.d/ifenslave: [ -f "/sys/class/net/$BOND_MASTER/bonding/slaves" ] && return network/if-pre-up.d/ifenslave: # If the bonding module is not yet loaded, load it. network/if-pre-up.d/ifenslave: if [ ! -r /sys/class/net/bonding_masters ]; then network/if-pre-up.d/ifenslave: modprobe -q bonding network/if-pre-up.d/ifenslave: if ! grep -sq "\\<$BOND_MASTER\\>" /sys/class/net/bonding_masters; then network/if-pre-up.d/ifenslave: echo "+$BOND_MASTER" > /sys/class/net/bonding_masters network/if-pre-up.d/ifenslave: # $1 = basename of the file in bonding/ to write to. network/if-pre-up.d/ifenslave: if ! grep -sq "\\<$2\\>" "/sys/class/net/$BOND_MASTER/bonding/$1" ; then network/if-pre-up.d/ifenslave: # $1 = basename of the file in bonding/ to write to. network/if-pre-up.d/ifenslave: echo "$2" > "/sys/class/net/$BOND_MASTER/bonding/$1" network/if-pre-up.d/ifenslave: if ! grep -sq "\\<$value\\>" /sys/class/net/$BOND_MASTER/bonding/$1 network/if-pre-up.d/ifenslave: # Double check in drivers/net/bonding/bond_sysfs.c in linux kernel source tree network/if-pre-up.d/ifenslave: echo "Failed to enslave $slave to $BOND_MASTER. Is $BOND_MASTER ready and a bonding interface ?" >&2 network/if-pre-up.d/ifenslave: # Bring up slave if it is the target of an allow-bondX stanza. network/if-pre-up.d/ifenslave: # Double check in drivers/net/bonding/bond_sysfs.c in linux kernel source tree network/if-pre-up.d/ifenslave: # The first slave in bond-primary found in current slaves becomes the primary. network/if-pre-up.d/ifenslave: # If no slave in bond-primary is found, then primary does not change. network/if-pre-up.d/ifenslave: if grep -sq "\\<$slave\\>" "/sys/class/net/$BOND_MASTER/bonding/slaves" ; then network/if-pre-up.d/ifenslave: # and after primary. This is currently (2.6.35-rc1) not enforced by the bonding driver, but it is network/if-pre-up.d/ifenslave:# Option slaves deprecated, replaced by bond-slaves, but still supported for backward compatibility. network/if-post-down.d/ifenslave: # $1 = basename of the file in bonding/ to write to. network/if-post-down.d/ifenslave: echo "$2" > "/sys/class/net/$IFACE/master/bonding/$1" network/if-post-down.d/ifenslave: read values < "/sys/class/net/$IFACE/bonding/$1" network/if-post-down.d/ifenslave: echo "-$value" > "/sys/class/net/$IFACE/bonding/$1" network/if-post-down.d/ifenslave:BOND_PARAMS="/sys/class/net/$IFACE/bonding" network/if-post-down.d/ifenslave:# free $IFACE if it is currently enslaved to a bonding device. network/if-post-down.d/ifenslave:if [ -f "/sys/class/net/$IFACE/master/bonding/slaves" ] ; then network/if-post-down.d/ifenslave: echo "-$IFACE" > "/sys/class/net/$IFACE/master/bonding/slaves" network/if-post-down.d/ifenslave: # The first slave in bond-primary found in current slaves becomes the primary. network/if-post-down.d/ifenslave: # If no slave in bond-primary is found, then primary does not change and might be undefined if just removed. network/if-post-down.d/ifenslave: if grep -sq "\\<$slave\\>" "/sys/class/net/$IFACE/master/bonding/slaves" ; then network/if-post-down.d/ifenslave: if [ -f "/sys/class/net/$slave/master/bonding/slaves" ] ; then openmediavault/config.xml: <bondiface> openmediavault/config.xml: <devicename>bond\d+</devicename> openmediavault/config.xml: <bondprimary>(eth|wlan)\d+</bondprimary> openmediavault/config.xml: <bondmode>0|1|2|3|4|5|6</bondmode> openmediavault/config.xml: <bondmiimon>0</bondmiimon> openmediavault/config.xml: <bonddowndelay>0</bonddowndelay> openmediavault/config.xml: <bondupdelay>0</bondupdelay> openmediavault/config.xml: </bondiface> openmediavault/config.xml: <devicename>bond0</devicename> openmediavault/config.xml: <options>bond-xmit_hash_policy layer3+4</options> openmediavault/config.xml: <type>bond</type> openmediavault/config.xml: <bondprimary/> openmediavault/config.xml: <bondmode>2</bondmode> openmediavault/config.xml: <bondmiimon>100</bondmiimon> openmediavault/config.xml: <bonddowndelay>200</bonddowndelay> openmediavault/config.xml: <bondupdelay>200</bondupdelay> -
Do they both show up in the web GUI? Can you delete bond0 from there?
-
You created both in the web gui?
-
Right, what did you to create bond0? I don't know if I can help you disable it unless I know how it's enabling in the first place. Linux boots with all network interfaces disabled and no bonding interfaces. Then, something, a script or a tool, turns things on a sets things up. There are a lot of ways that could be happening so I need to know how it started in the first place.
/etc/sysconfig is, I believe, a Red Hat way of configuring networking and Debian (upon which OMV is based) doesn't do that. My system doesn't have an /etc/sysconfig at all. My guess is that you followed some instructions designed for Red Hat and that's what's causing the confusion.
-
Yes, and I'm not sure what that means. Do you mean will the ACLs show up in the web GUI? I'm not sure. Will they work with other things that OMV does? Sure. FACLs are pretty well supported in Linux.
-
Huh. If it's not in there then I'm not sure how it's starting up at all. What did you do to try to enable bonding?
-
It's pretty easy, I'd just fork the openmediavault-zfs project on github, make the change, and create a pull request back to the original project.
-
The torrent daemon runs as the "debian-transmission" user. That user will need to have access to whatever directory he's trying to download to. However, when it creates files, it'll create them owned by it. I would recommend using FACLs to set this up. Let's pretend you want these files to go into "/data/torrent/downloads". I would put your friend's user into some group, I'll call it "Torrenters" and then do:
chown -R nobody:Torrenters /data/torrent/downloads
chmod -R u+rwX,g+rwX,o-rwX /data/torrent/downloads
setfacl -R -m u:debian-transmission:rwX /data/torrent/downloads
setfacl -R -m d:u:debian-transmission:rwX /data/torrent/downloads
setfacl -R -m d:g:Torrenters:rwX /data/torrent/downloadsWhat this does is the following:
- Set the ownership of the download directory to be owned by no user and the Torrenters group
- Set the directory to be readable (r), writable (w), and executable (X) by the owner user and groups and no one else.
- Add a File Access Control entry that gives the user (u) debian-transmission read, write, and execute on that directory.
- Add a File Access Control entry that will default (d) to giving the user (u) debian-transmission read (r), write (w), and execute (X) on any new files or directories created in that directory.
- Add a File Access Control entry that will default (d) to giving the group (g) Torrenters read (r), write (w), and execute (x) on any new files and directories created in that directory.Note that "-R" makes it recursive, so all of the contents will receive these settings and using a capitol X instead of a lowercase x means that only those files that are already executable will be granted these new executable permissions (including directories). This is a useful way of setting execute only on those files where it's necessary. So with the default ACLs, if you create a new regular file or you torrent a regular file, it will not be executable by anyone. As soon as you "chmod +x" it, it should be executable by everyone with the proper default ACL.
-
Are you rebooting the system? Because none of these commands are permanent. You need to change the OpenMediaVault config and/or /etc/network/interfaces.
-
It's literally "bond", you don't need to specify the device. You're removing the bond module from the kernel.
-
According to this presentation: http://www.usb.org/developers/…res0602/john_macinnis.pdf, most older BIOSes that support USB 2.0 will configure them for USB 1.0 until the OS reconfigures them. I'll check what my BIOS is set to but Linux claims, in the above output, that it's configured it for USB 2.0.
-
Indeed I'm terrified of losing the hardware controller and thus losing the RAID because it's stored in the thing's BIOS or something. Or those fake hardware RAID controllers, or weird Linux driver incompatibilities. Machines these days are fast enough to do RAID in software quite well, especially if you do something like ZFS.
-
According to `lsusb`:
Code
Display MoreBus 001 Device 004: ID 0781:5583 SanDisk Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0781 SanDisk Corp. idProduct 0x5583 bcdDevice 1.00 iManufacturer 1 SanDisk iProduct 2 Ultra Fit iSerial 3 4C530001020208115280 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 224mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Status: 0x0000 (Bus Powered)However, you might be right that the BIOS runs the USB device at 1.0 and it only flips it to 2.0 once the kernel boots. That might make sense.