Skip to content
This repository has been archived by the owner on Feb 26, 2020. It is now read-only.

Bad Request issue when mounting bucket in openstack swift Mitaka #128

Open
janibashamd opened this issue Apr 11, 2017 · 12 comments
Open

Bad Request issue when mounting bucket in openstack swift Mitaka #128

janibashamd opened this issue Apr 11, 2017 · 12 comments
Labels

Comments

@janibashamd
Copy link

Context

  • svfs version : 0.9.1
  • storage provider : Openstack Mitaka
  • product : CentOS7

Steps to reproduce this issue :

  1. Install Openstack Mitaka and create bucket
  2. Install svfs and source openrc file
  3. Mount the bucket

Results you expected :

Bucket should be mounted

Results you observed :

FATA[2017-04-11T16:25:32+05:30] Bad Request

Debug log :

[root@centos ~]# sudo mount -t svfs -o username=$OS_USERNAME,password=$OS_PASSWORD,project=$OS_PROJECT_NAME,url=$OS_AUTH_URL,debug=true dhanu /mnt/svfs/
[root@centos ~]# DEBU[2017-04-11T16:25:30+05:30] Skipping configuration : open : no such file or directory source=svfs
FATA[2017-04-11T16:25:32+05:30] Bad Request

Additional information :

[root@centos ~]# env | grep OS_*
HOSTNAME=centos
OS_REGION_NAME=RegionOne
OS_USER_DOMAIN_NAME=default
OS_IMAGE_API_VERSION=2
OS_PROJECT_NAME=admin
OS_IDENTITY_API_VERSION=3
OS_PASSWORD=vedams123
OS_AUTH_URL=http://192.168.12.175:35357/v3
OS_USERNAME=admin
OS_TENANT_NAME=admin
OS_PROJECT_DOMAIN_NAME=default

[root@centos ~]# swift list
con1
dhanu

Is this compatible with swift Mitaka version ?

Please help me with this issue. If need more info will be happy to provide..

@xlucas
Copy link
Contributor

xlucas commented Apr 11, 2017

Hello, can you use auth v2 instead ? Authentication v3 is not supported/tested yet.

Also make sure you use sudo -E to avoid user's env vars to be stripped.

@janibashamd
Copy link
Author

janibashamd commented Apr 13, 2017

Hai, thanks for the update.

I have used keystone v2.0 and later tried svfs mount command after which able to mount swift bucket locally.
No issues in accessing and created files/objects.

Then i tried to access this mounted bucket to another client using nfs but getting
read-only permission issue.

Steps done -

  1. Installed nfs server and client
  2. Exported bucket mounted location to another client
  3. Mounted this nfsserver location locallly in nfs client
  4. I am able to list objects
    [root@gluster ~]# ls /mnt/nfs/

Server side -
[root@centos ~]# cat /etc/exports
/root/nfs 192.168.12.73(rw,insecure,no_root_squash,sync,no_subtree_check,fsid=0)

Client side -
root@s3fsvm:~# mount -o rw 192.168.12.175:/root/nfs/ /mnt/nfs/

When i tried to create new files getting below error -
root@s3fsvm:/mnt/nfs# touch luck
touch: cannot touch ‘luck’: Input/output error

Previously without svfs nfs was working fine so i think your code is blocking nfs services.

Any suggestions or recommendations would be really helpful..

Once again thanks for the above suggestion.....
have a great day.

@janibashamd
Copy link
Author

root@s3fsvm:~# touch /mnt/april13/system
touch: cannot touch ‘/mnt/april13/system’: Input/output error

svfs debug log -
DEBU[2017-03-06T19:27:32+05:30] <- Getattr [ID=0x70 Node=0x1 Uid=0 Gid=0 Pid=9075] 0x0 fl=0 source=fuse
DEBU[2017-03-06T19:27:32+05:30] -> [ID=0x70] Getattr valid=1m0s ino=1 size=4096 mode=d--------- source=fuse
DEBU[2017-03-06T19:27:32+05:30] <- Lookup [ID=0x71 Node=0x1 Uid=0 Gid=0 Pid=9075] "system" source=fuse
DEBU[2017-03-06T19:27:36+05:30] -> [ID=0x71] Lookup error=ENOENT source=fuse
DEBU[2017-03-06T19:27:36+05:30] <- Getxattr [ID=0x72 Node=0x1 Uid=0 Gid=0 Pid=9075] "system.posix_acl_default" 0 @0 source=fuse
DEBU[2017-03-06T19:27:36+05:30] -> [ID=0x72] Getxattr error=operation not supported source=fuse
DEBU[2017-03-06T19:27:36+05:30] <- Lookup [ID=0x73 Node=0x1 Uid=0 Gid=0 Pid=9075] "system" source=fuse
DEBU[2017-03-06T19:27:36+05:30] -> [ID=0x73] Lookup error=ENOENT source=fuse
DEBU[2017-03-06T19:27:36+05:30] <- Mknod [ID=0x74 Node=0x1 Uid=0 Gid=0 Pid=9075] Name "system" mode=-rw-r--r-- umask=---------- rdev=0 source=fuse
DEBU[2017-03-06T19:27:36+05:30] -> [ID=0x74] Mknod error=EIO source=fuse
DEBU[2017-03-06T19:27:36+05:30] <- Lookup [ID=0x75 Node=0x1 Uid=0 Gid=0 Pid=9075] "system" source=fuse
DEBU[2017-03-06T19:27:36+05:30] -> [ID=0x75] Lookup error=ENOENT source=fuse

@xlucas
Copy link
Contributor

xlucas commented Apr 14, 2017

Hello, if you provide an svfs mount through NFS, you have to make sure uid/gid are correctly mapped between the client machine and the server or set up uid/gid squashing. You probably need to tune permissions options, there are several issues in this project where people ask about permissions and I explained quite a few times in these relevant options.

touch(1) requires the possibility to set times on files, check the attr mount option for this.

@janibashamd
Copy link
Author

janibashamd commented Apr 14, 2017

[root@centos ~]# svfs mount --device april13 --mountpoint /mnt/april13 --default-mode 777 --allow-other --debug --readdir-extended-attributes --os-auth-url http://192.168.12.175:35357/v2.0 --os-password vedams123 --os-username admin --os-container-name april13 --os-region-name RegionOne --os-tenant-name admin

Server side -
[root@centos ~]# umask
0022
[root@centos ~]# id -u root
0
[root@centos ~]# id -g root
0

Client side -
root@s3fsvm:umask
0022
root@s3fsvm:
id -u root
0
root@s3fsvm:~ id -g root
0

We tried with multiple permissions, umask, --default-mode options, allow_other and client side mount options still facing the same issue..

We checked another local NFS share and its working without issues..

@xlucas
Copy link
Contributor

xlucas commented Apr 14, 2017

The root cause is that nfs relies on mknod(2) server-side which is not supported by svfs.

@xlucas xlucas added the usage label Apr 14, 2017
@janibashamd
Copy link
Author

janibashamd commented Apr 17, 2017

Hai Lucas,

Thanks so much for such a quick reply. No-one in git hub replied as quick as you !!!!..

Please let me know if there is any work-around or any changes we can make to achieve the target.

@janibashamd
Copy link
Author

Hai Lucas,

Any update will be really appreciated... :)

@janibashamd
Copy link
Author

Hai Lucas,

Is this issue because mknod is not supported by svfs or its a fuse not supported ??

@xlucas
Copy link
Contributor

xlucas commented May 2, 2017

Hi, this is not supported by svfs since this doesn't make sense when you have a storage endpoint like Swift.

@janibashamd
Copy link
Author

Hi Lucas,

Thanks for the answer.

Can you let me know if there is any proper gateway for Openstack Swift<-->NFS access.
I tried multiple components but facing issues.

@maheshb15
Copy link

Is there any way to change default umask(mount permission for the swift bucket) ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants