Permissões em compartilhamentos samba 4
Galera boa tarde! Alguém de vocês já implantou domain controller com samba 4 incluindo compartilhamento de arquivos com permissões por usuários e não grupos? Teria como fazer? -- Diego Monte User Linux#402556 ~ °v° Seja Livre... /( )\ Use Linux... ^ ^
Re: Permissões de acesso a arquivos shadow com e sem sudo
Olá, as permissões padrões mudam de distro para distro. No Debian o padrão é 640 mesmo, o sudo não altera permissões destes arquivos, não tem ligação com a constatação que você fez. Abraço. Em 14-03-2013 11:49, jacinto minhas pernas escreveu: Amigos, Estou estudando para o exame LPIC 102 e nos estudos descobri que as permissões de acesso aos arquivos shadow é, por padrão, 400. Quando fui verificar em minha máquina, percebi que os referidos arquivos estavam com a permissão 640, sendo o grupo shadow. Eis a dúvida: Esta mudança de permissões se deve ao fato de o sudo estar instalado? (supús que talvez fosse o único utilitário que precisasse acessar as senhas shadow) Abraços -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1644785024.2433233.1363272592180.javamail.tomc...@ibriss06.dlan.cinetic.de -- Att. Dane Brand Atua Sistemas de Informação Skype: dane.atua Msn: d...@atua.com.br ICQ : 126258686 Fone: (54) 3045-4144 Celular: (54) 9673-8919 Linux User #548369 LPIC 3 - CORE -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5141e4df.2050...@atua.com.br
Re: Permissões de acesso a arquivos shadow com e sem sudo
Foi o que eu lhe expliquei, O sudo não tem motivo para alterar o /etc/shadow, sendo assim ele não altera a permissão. No Debian a permissão padrão é 640 é não 400 como você está dizendo. Veja um exemplo de uma máquina sem do sudo instalado. root@debian:~# dpkg -l |grep sudo root@debian:~# stat -c %a /etc/shadow 640 A permissão não tem haver com o sudo, e sim o padrão do SO. Em 14-03-2013 12:35, jacinto minhas pernas escreveu: Dane, Eu sei o conceito de permissões padrão, mas a questão não é essa. A permissão de um arquivo shadow é 400, ou seja, somente leitura para o root e ninguém mais. Do contrário, não haveria sentido na existência dele. O que eu percebi é que em todos os sistemas que opero que possuem o sudo instalado, a permissão do /etc/shadow é 640, sendo o root o proprietário e com o grupo shadow. Eu só queria confirmar se esta mudança nas permissões é feita mesmo pelo sudo, ou por outro utilitário. Abraços At 14 Mar 2013 14:55:27 + (UTC) de Dane d...@atua.com.br: Olá, as permissões padrões mudam de distro para distro. No Debian o padrão é 640 mesmo, o sudo não altera permissões destes arquivos, não tem ligação com a constatação que você fez. Abraço. Em 14-03-2013 11:49, jacinto minhas pernas escreveu: Amigos, Estou estudando para o exame LPIC 102 e nos estudos descobri que as permissões de acesso aos arquivos shadow é, por padrão, 400. Quando fui verificar em minha máquina, percebi que os referidos arquivos estavam com a permissão 640, sendo o grupo shadow. Eis a dúvida: Esta mudança de permissões se deve ao fato de o sudo estar instalado? (supús que talvez fosse o único utilitário que precisasse acessar as senhas shadow) Abraços -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1644785024.2433233.1363272592180.javamail.tomc...@ibriss06.dlan.cinetic.de -- Att. Dane Brand Atua Sistemas de Informação Skype: dane.atua Msn: d...@atua.com.br ICQ : 126258686 Fone: (54) 3045-4144 Celular: (54) 9673-8919 Linux User #548369 LPIC 3 - CORE -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5141e4df.2050...@atua.com.br -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1365768639.2439231.1363275349668.javamail.tomc...@ibriss06.dlan.cinetic.de -- Att. Dane Brand Atua Sistemas de Informação Skype: dane.atua Msn: d...@atua.com.br ICQ : 126258686 Fone: (54) 3045-4144 Celular: (54) 9673-8919 Linux User #548369 LPIC 3 - CORE
Re: Permissões de acesso a arquivos shadow com e sem sudo
Que bom cara, espero ter te ajudado em algo. Tem bastante coisas na LPI, que confundem usuários do Debian, pq ele acaba fazendo de uma forma diferente ou facilitando algumas coisas, e isto não ocorre nas outras distros. Em 14-03-2013 13:42, jacinto minhas pernas escreveu: Dane, Agora entendi sua explicação. Eu tinha achado que o sudo tivesse alguma coisa a ver, uma vez que, quando usado, ele faz uso das senhas shadow. Obrigado Abraços At 14 Mar 2013 15:59:53 + (UTC) de Dane d...@atua.com.br: Foi o que eu lhe expliquei, O sudo não tem motivo para alterar o /etc/shadow, sendo assim ele não altera a permissão. No Debian a permissão padrão é 640 é não 400 como você está dizendo. Veja um exemplo de uma máquina sem do sudo instalado. root@debian:~# dpkg -l |grep sudo root@debian:~# stat -c %a /etc/shadow 640 A permissão não tem haver com o sudo, e sim o padrão do SO. Em 14-03-2013 12:35, jacinto minhas pernas escreveu: Dane, Eu sei o conceito de permissões padrão, mas a questão não é essa. A permissão de um arquivo shadow é 400, ou seja, somente leitura para o root e ninguém mais. Do contrário, não haveria sentido na existência dele. O que eu percebi é que em todos os sistemas que opero que possuem o sudo instalado, a permissão do /etc/shadow é 640, sendo o root o proprietário e com o grupo shadow. Eu só queria confirmar se esta mudança nas permissões é feita mesmo pelo sudo, ou por outro utilitário. Abraços At 14 Mar 2013 14:55:27 + (UTC) de Dane d...@atua.com.br: Olá, as permissões padrões mudam de distro para distro. No Debian o padrão é 640 mesmo, o sudo não altera permissões destes arquivos, não tem ligação com a constatação que você fez. Abraço. Em 14-03-2013 11:49, jacinto minhas pernas escreveu: Amigos, Estou estudando para o exame LPIC 102 e nos estudos descobri que as permissões de acesso aos arquivos shadow é, por padrão, 400. Quando fui verificar em minha máquina, percebi que os referidos arquivos estavam com a permissão 640, sendo o grupo shadow. Eis a dúvida: Esta mudança de permissões se deve ao fato de o sudo estar instalado? (supús que talvez fosse o único utilitário que precisasse acessar as senhas shadow) Abraços -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1644785024.2433233.1363272592180.javamail.tomc...@ibriss06.dlan.cinetic.de -- Att. Dane Brand Atua Sistemas de Informação Skype: dane.atua Msn: d...@atua.com.br ICQ : 126258686 Fone: (54) 3045-4144 Celular: (54) 9673-8919 Linux User #548369 LPIC 3 - CORE -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5141e4df.2050...@atua.com.br -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1365768639.2439231.1363275349668.javamail.tomc...@ibriss06.dlan.cinetic.de -- Att. Dane Brand Atua Sistemas de Informação Skype: dane.atua Msn:d...@atua.com.br ICQ : 126258686 Fone: (54) 3045-4144 Celular: (54) 9673-8919 Linux User #548369 LPIC 3 - CORE -- Att. Dane Brand Atua Sistemas de Informação Skype: dane.atua Msn: d...@atua.com.br ICQ : 126258686 Fone: (54) 3045-4144 Celular: (54) 9673-8919 Linux User #548369 LPIC 3 - CORE
Re: Permissões de acesso a arquivos shadow com e sem sudo
O conceito do sudo é super user do, ou seja faça como root. Sendo assim, sudo herda permissões root; att On 14/03/13 at 12:59pm, Dane wrote: Date: Thu, 14 Mar 2013 12:59:53 -0300 From: Dane d...@atua.com.br To: debian-user-portuguese@lists.debian.org Subject: Re: Permissões de acesso a arquivos shadow com e sem sudo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 Foi o que eu lhe expliquei, O sudo não tem motivo para alterar o /etc/shadow, sendo assim ele não altera a permissão. No Debian a permissão padrão é 640 é não 400 como você está dizendo. Veja um exemplo de uma máquina sem do sudo instalado. root@debian:~# dpkg -l |grep sudo root@debian:~# stat -c %a /etc/shadow 640 A permissão não tem haver com o sudo, e sim o padrão do SO. Em 14-03-2013 12:35, jacinto minhas pernas escreveu: Dane, Eu sei o conceito de permissões padrão, mas a questão não é essa. A permissão de um arquivo shadow é 400, ou seja, somente leitura para o root e ninguém mais. Do contrário, não haveria sentido na existência dele. O que eu percebi é que em todos os sistemas que opero que possuem o sudo instalado, a permissão do /etc/shadow é 640, sendo o root o proprietário e com o grupo shadow. Eu só queria confirmar se esta mudança nas permissões é feita mesmo pelo sudo, ou por outro utilitário. Abraços At 14 Mar 2013 14:55:27 + (UTC) de Dane d...@atua.com.br: Olá, as permissões padrões mudam de distro para distro. No Debian o padrão é 640 mesmo, o sudo não altera permissões destes arquivos, não tem ligação com a constatação que você fez. Abraço. Em 14-03-2013 11:49, jacinto minhas pernas escreveu: Amigos, Estou estudando para o exame LPIC 102 e nos estudos descobri que as permissões de acesso aos arquivos shadow é, por padrão, 400. Quando fui verificar em minha máquina, percebi que os referidos arquivos estavam com a permissão 640, sendo o grupo shadow. Eis a dúvida: Esta mudança de permissões se deve ao fato de o sudo estar instalado? (supús que talvez fosse o único utilitário que precisasse acessar as senhas shadow) Abraços -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1644785024.2433233.1363272592180.javamail.tomc...@ibriss06.dlan.cinetic.de -- Att. Dane Brand Atua Sistemas de Informação Skype: dane.atua Msn: d...@atua.com.br ICQ : 126258686 Fone: (54) 3045-4144 Celular: (54) 9673-8919 Linux User #548369 LPIC 3 - CORE -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5141e4df.2050...@atua.com.br -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1365768639.2439231.1363275349668.javamail.tomc...@ibriss06.dlan.cinetic.de -- Att. Dane Brand Atua Sistemas de Informação Skype: dane.atua Msn: d...@atua.com.br ICQ : 126258686 Fone: (54) 3045-4144 Celular: (54) 9673-8919 Linux User #548369 LPIC 3 - CORE -- Francisco Aparecido da Silva (fafanet) -- Blog: http://blog.silva.eti.br http://www.twitter.com/fafanete http://www.identi.ca/fafanet GNU/Linux user:239412 GPG ID:01BC73D6 -- signature.asc Description: Digital signature
Re: problema nas permissões
Ja tentou montar como ROOT ? Em 2 de dezembro de 2012 23:27, Angela Ferreira angehisto...@hotmail.comescreveu: Olá Então, minha sourceslist está assim: # # deb cdrom:[Debian GNU/Linux 6.0.6 _Squeeze_ - Official i386 NETINST Binary-1 20120930-15:55]/ squeeze main #deb cdrom:[Debian GNU/Linux 6.0.6 _Squeeze_ - Official i386 NETINST Binary-1 20120930-15:55]/ squeeze main deb http://ftp.br.debian.org/debian/ squeeze main deb-src http://ftp.br.debian.org/debian/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-updates, previously known as 'volatile' deb http://ftp.br.debian.org/debian/ squeeze-updates main deb-src http://ftp.br.debian.org/debian/ squeeze-updates main # squeeze non-free deb http://ftp.br.debian.org/debian/ squeeze main contrib non-free deb-src http://ftp.br.debian.org/debian squeeze main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free :) Angela -- Date: Mon, 3 Dec 2012 01:14:23 -0200 Subject: Re: problema nas permissões From: professorques...@gmail.com To: angehisto...@hotmail.com CC: kleber...@yahoo.com.br; debian-user-portuguese@lists.debian.org Ola Apenas para constar na sua lista de repositórios (/etc/apt/sources.list) existe as categorias contrib non-free depois de main? E quais repositórios estão na lista? Abraços 2012/12/3 Angela Ferreira angehisto...@hotmail.com Olá Kleber, obrigada pela atenção, mas infelizmente quando tento instalar aptitude install ntfs-3g ntfsprogs diz que o programa n pode ser instalado: nenhum pacote será instalado, atualizado ou removido. 0 pacotes atualizados, 0 novos instalados, 0 a serem removidos e 3 não atualizados. É preciso obter 0 B de arquivos. Depois do desempacotamento, 0 B serão usados. Continuei os passos seguintes mas não obtive sucesso. Nao apareceu nada quando inseri os comandos 7 e 8... Visualizei que o HD externo não é mais reconhecido mesmo conectado. Antes conseguia visualiza-lo no dolphin com uma msg de erro. :( Muitissimo obrigada pela atenção! Angela -- Date: Sun, 2 Dec 2012 23:02:53 -0200 From: kleber...@yahoo.com.br To: angehisto...@hotmail.com CC: adrian...@gmail.com; debian-user-portuguese@lists.debian.org Subject: Re: problema nas permissões Boa noite! Provavelmente você não tem o pacote de aplicativos padrão para o NTFS. Faça o seguinte: 1) Abra um Terminal *Menu Aplicativos - Acessórios - Terminal* 2) Mude para o usuário root (administrador), digitando o comando a seguir e colocando a senha (ao digitar, não aparecerá nenhum digito) *su -* 3) Copie e cole o comando abaixo echo deb http://ftp.debian.org/debian stable main contrib non-free /etc/apt/sources.list 4) Atualize a lista de pacotes de aplicativos do sistema aptitude update 5) Instale os programas abaixo aptitude install ntfs-3g ntfsprogs 6) Coloque seu usuário nos grupos abaixo adduser angela plugdev 7) Tente colocar o HD externo na porta USB, deverá abrir automaticamente. Caso não funcione, execute, ainda como root (Administrador) o comando abaixo (pode copiar/colar) mkdir /media/hd mount -t ntfs-3g */dev/sdb1* /media/hd Obs: O que está em negrito é a partição do seu HD externo. Desta forma entendemos que você tem um HD no sistema, chamado de /dev/sda1 e que o HD externo será o segundo disco. Caso você tenha mais HD's no sistema, é mudar o sdb1 para sd*c*1, sd*d*1, etc 8) Para conferir se deu certo, após a execução do comando anterior, execute os comando abaixo df -h | grep media No comando acima deverá aparecer a montagem do disco. Se montar deverá aparecer algo. Parabéns, deu certo, se não ver nada...vamos chorar...rsrs ls /media/hd No comando acima deverá aparecer os arquivos do HD externo, caso tenha. Posta aí os resultados depois, ok! Até mais -- Kleber Melo Admin. Sistemas Linux Advanced Level - Linux Professional Institute Certificate (LPIC-2) Novell Certified Linux Administrator (CLA) Novell Data Center Technical Specialist (DCT) Skype: kleber.melo
Re: problema nas permissões
Não é necessário repetir as linhas para incluir os pacotes non-free. O correto seria: deb http://ftp.br.debian.org/debian/ squeeze main contrib non-free deb-src http://ftp.br.debian.org/debian/ squeeze main contrib non-free deb http://security.debian.org/ squeeze/updates main contrib non-free deb-src http://security.debian.org/ squeeze/updates main contrib non-free # squeeze-updates, previously known as 'volatile' deb http://ftp.br.debian.org/debian/ squeeze-updates main contrib non-free deb-src http://ftp.br.debian.org/debian/ squeeze-updates main contrib non-free Não sei se é por isso que você não está conseguindo instalar os pacotes, mas deixa o arquivo mais simples. Você pode editar o arquivo /etc/apt/sources.list usando o editor nano (nano /etc/apt/sources.list). Depois disso, atualize os repositórios e instale o pacote ntfs-3g: apt-get update apt-get install ntfs-3g Se preferir, troque o apt-get pelo aptitude que dá na mesma tb. Tente montar o HD e se não der certo, deslogue e logue novamente. On Mon, 3 Dec 2012 06:27:27 +0300 Angela Ferreira angehisto...@hotmail.com wrote: Olá Então, minha sourceslist está assim: # # deb cdrom:[Debian GNU/Linux 6.0.6 _Squeeze_ - Official i386 NETINST Binary-1 20120930-15:55]/ squeeze main #deb cdrom:[Debian GNU/Linux 6.0.6 _Squeeze_ - Official i386 NETINST Binary-1 20120930-15:55]/ squeeze main deb http://ftp.br.debian.org/debian/ squeeze main deb-src http://ftp.br.debian.org/debian/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-updates, previously known as 'volatile' deb http://ftp.br.debian.org/debian/ squeeze-updates main deb-src http://ftp.br.debian.org/debian/ squeeze-updates main # squeeze non-free deb http://ftp.br.debian.org/debian/ squeeze main contrib non-free deb-src http://ftp.br.debian.org/debian squeeze main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free :) Angela Date: Mon, 3 Dec 2012 01:14:23 -0200 Subject: Re: problema nas permissões From: professorques...@gmail.com To: angehisto...@hotmail.com CC: kleber...@yahoo.com.br; debian-user-portuguese@lists.debian.org Ola Apenas para constar na sua lista de repositórios (/etc/apt/sources.list)existe as categorias contrib non-free depois de main? E quais repositórios estão na lista? Abraços 2012/12/3 Angela Ferreira angehisto...@hotmail.com Olá Kleber, obrigada pela atenção, mas infelizmente quando tento instalar aptitude install ntfs-3g ntfsprogs diz que o programa n pode ser instalado: nenhum pacote será instalado, atualizado ou removido. 0 pacotes atualizados, 0 novos instalados, 0 a serem removidos e 3 não atualizados. É preciso obter 0 B de arquivos. Depois do desempacotamento, 0 B serão usados. Continuei os passos seguintes mas não obtive sucesso. Nao apareceu nada quando inseri os comandos 7 e 8... Visualizei que o HD externo não é mais reconhecido mesmo conectado. Antes conseguia visualiza-lo no dolphin com uma msg de erro. :( Muitissimo obrigada pela atenção! Angela Date: Sun, 2 Dec 2012 23:02:53 -0200 From: kleber...@yahoo.com.br To: angehisto...@hotmail.com CC: adrian...@gmail.com; debian-user-portuguese@lists.debian.org Subject: Re: problema nas permissões Boa noite! Provavelmente você não tem o pacote de aplicativos padrão para o NTFS. Faça o seguinte: 1) Abra um Terminal Menu Aplicativos - Acessórios - Terminal 2) Mude para o usuário root (administrador), digitando o comando a seguir e colocando a senha (ao digitar, não aparecerá nenhum digito) su - 3) Copie e cole o comando abaixo echo deb http://ftp.debian.org/debian stable main contrib non-free /etc/apt/sources.list 4) Atualize a lista de pacotes de aplicativos do sistema aptitude update 5) Instale os programas abaixo aptitude install ntfs-3g ntfsprogs 6) Coloque seu usuário nos grupos abaixo adduser angela plugdev 7) Tente colocar o HD externo na porta USB, deverá abrir automaticamente. Caso não funcione, execute, ainda como root (Administrador) o comando abaixo (pode copiar/colar) mkdir /media/hd mount -t ntfs-3g /dev/sdb1 /media/hd Obs: O que está em negrito é a partição do seu HD externo. Desta forma entendemos que você tem um HD no sistema, chamado de /dev/sda1 e que o HD externo será o segundo disco. Caso você tenha mais HD's no sistema, é mudar o sdb1 para sdc1, sdd1, etc 8) Para conferir se deu certo, após a execução do comando
problema nas permissões
Ola, Estou utilizando o debian 6 com KDE e quando coloco um hd externo ele acusa o seguinte erro: Um erro ocorreu ao acessar 'HD EXTERNO', o sistema informou: ntfs-3g-mount: failed to open /dev/fuse: permissão negada. Podem me ajudar a resolver este problema com um passo a passo? sou iniciante. Obrigada desde já pela atenção. Angela
Re: problema nas permissões
Em Mon, 3 Dec 2012 00:05:27 +0300 Angela Ferreira angehisto...@hotmail.com escreveu: Ola, Estou utilizando o debian 6 com KDE e quando coloco um hd externo ele acusa o seguinte erro: Um erro ocorreu ao acessar 'HD EXTERNO', o sistema informou: ntfs-3g-mount: failed to open /dev/fuse: permissão negada. Podem me ajudar a resolver este problema com um passo a passo? sou iniciante. Obrigada desde já pela atenção. Angela Olá. Talvez a causa do problema seja você não estar no grupo fuse. Abra um terminal/console e digite o seguinte comando, substituindo angela pelo seu nome de usuária: sudo adduser angela fuse signature.asc Description: PGP signature
RE: problema nas permissões
Obrigada Adriano mas infelizmente a sua dica não deu certo. Fiz o passo a passo e disse que inseriu meu nome, mas mesmo assim não consigo acessar o hd externo. Agradeço a atenção. Date: Sun, 2 Dec 2012 19:25:23 -0200 From: adrian...@gmail.com To: debian-user-portuguese@lists.debian.org Subject: Re: problema nas permissões Em Mon, 3 Dec 2012 00:05:27 +0300 Angela Ferreira angehisto...@hotmail.com escreveu: Ola, Estou utilizando o debian 6 com KDE e quando coloco um hd externo ele acusa o seguinte erro: Um erro ocorreu ao acessar 'HD EXTERNO', o sistema informou: ntfs-3g-mount: failed to open /dev/fuse: permissão negada. Podem me ajudar a resolver este problema com um passo a passo? sou iniciante. Obrigada desde já pela atenção. Angela Olá. Talvez a causa do problema seja você não estar no grupo fuse. Abra um terminal/console e digite o seguinte comando, substituindo angela pelo seu nome de usuária: sudo adduser angela fuse
Re: problema nas permissões
Em Mon, 3 Dec 2012 00:43:05 +0300 Angela Ferreira angehisto...@hotmail.com escreveu: Obrigada Adriano mas infelizmente a sua dica não deu certo. Fiz o passo a passo e disse que inseriu meu nome, mas mesmo assim não consigo acessar o hd externo. Agradeço a atenção. Esqueci de dizer que é necessário fazer logout e login para a nova permissão ter efeito. signature.asc Description: PGP signature
RE: problema nas permissões
Adriano, infelizmente não deu certo. Agora a mensagem aumentou, veja só: Um erro ocorreu ao acessar 'HD EXTERNO', o sistema informou: ntfs-3g-mount: failed to open /dev/fuse: permissão negada. User doesn't have privilege to mount. For more information please see: http://ntfs-3g.org/support.html#unprivileged Novamente obrigada! Date: Sun, 2 Dec 2012 19:47:04 -0200 From: adrian...@gmail.com To: debian-user-portuguese@lists.debian.org Subject: Re: problema nas permissões Em Mon, 3 Dec 2012 00:43:05 +0300 Angela Ferreira angehisto...@hotmail.com escreveu: Obrigada Adriano mas infelizmente a sua dica não deu certo. Fiz o passo a passo e disse que inseriu meu nome, mas mesmo assim não consigo acessar o hd externo. Agradeço a atenção. Esqueci de dizer que é necessário fazer logout e login para a nova permissão ter efeito.
Re: problema nas permissões
Boa noite! Provavelmente voc no tem o pacote de aplicativos padro para o NTFS. Faa o seguinte: 1) Abra um Terminal Menu Aplicativos - Acessrios - Terminal 2) Mude para o usurio root (administrador), digitando o comando a seguir e colocando a senha (ao digitar, no aparecer nenhum digito) su - 3) Copie e cole o comando abaixo echo "deb http://ftp.debian.org/debian stable main contrib non-free" /etc/apt/sources.list 4) Atualize a lista de pacotes de aplicativos do sistema aptitude update 5) Instale os programas abaixo aptitude install ntfs-3g ntfsprogs 6) Coloque seu usurio nos grupos abaixo adduser angela plugdev 7) Tente colocar o HD externo na porta USB, dever abrir automaticamente. Caso no funcione, execute, ainda como root (Administrador) o comando abaixo (pode copiar/colar) mkdir /media/hd mount -t ntfs-3g /dev/sdb1 /media/hd Obs: O que est em negrito a partio do seu HD externo. Desta forma entendemos que voc tem um HD no sistema, chamado de /dev/sda1 e que o HD externo ser o segundo disco. Caso voc tenha mais HD's no sistema, mudar o "sdb1" para "sdc1", sdd1", etc 8) Para conferir se deu certo, aps a execuo do comando anterior, execute os comando abaixo df -h | grep media No comando acima dever aparecer a montagem do disco. Se montar dever aparecer algo. Parabns, deu certo, se no ver nada...vamos chorar...rsrs ls /media/hd No comando acima dever aparecer os arquivos do HD externo, caso tenha. Posta a os resultados depois, ok! At mais -- Kleber Melo Admin. Sistemas Linux Advanced Level - Linux Professional Institute Certificate (LPIC-2) Novell Certified Linux Administrator (CLA) Novell Data Center Technical Specialist (DCT) Skype: kleber.melo -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50bbfa3d.2080...@yahoo.com.br
RE: problema nas permissões
Olá Kleber, obrigada pela atenção, mas infelizmente quando tento instalar aptitude install ntfs-3g ntfsprogs diz que o programa n pode ser instalado: nenhum pacote será instalado, atualizado ou removido. 0 pacotes atualizados, 0 novos instalados, 0 a serem removidos e 3 não atualizados. É preciso obter 0 B de arquivos. Depois do desempacotamento, 0 B serão usados. Continuei os passos seguintes mas não obtive sucesso. Nao apareceu nada quando inseri os comandos 7 e 8... Visualizei que o HD externo não é mais reconhecido mesmo conectado. Antes conseguia visualiza-lo no dolphin com uma msg de erro. :( Muitissimo obrigada pela atenção! Angela Date: Sun, 2 Dec 2012 23:02:53 -0200 From: kleber...@yahoo.com.br To: angehisto...@hotmail.com CC: adrian...@gmail.com; debian-user-portuguese@lists.debian.org Subject: Re: problema nas permissões Boa noite! Provavelmente você não tem o pacote de aplicativos padrão para o NTFS. Faça o seguinte: 1) Abra um Terminal Menu Aplicativos - Acessórios - Terminal 2) Mude para o usuário root (administrador), digitando o comando a seguir e colocando a senha (ao digitar, não aparecerá nenhum digito) su - 3) Copie e cole o comando abaixo echo deb http://ftp.debian.org/debian stable main contrib non-free /etc/apt/sources.list 4) Atualize a lista de pacotes de aplicativos do sistema aptitude update 5) Instale os programas abaixo aptitude install ntfs-3g ntfsprogs 6) Coloque seu usuário nos grupos abaixo adduser angela plugdev 7) Tente colocar o HD externo na porta USB, deverá abrir automaticamente. Caso não funcione, execute, ainda como root (Administrador) o comando abaixo (pode copiar/colar) mkdir /media/hd mount -t ntfs-3g /dev/sdb1 /media/hd Obs: O que está em negrito é a partição do seu HD externo. Desta forma entendemos que você tem um HD no sistema, chamado de /dev/sda1 e que o HD externo será o segundo disco. Caso você tenha mais HD's no sistema, é mudar o sdb1 para sdc1, sdd1, etc 8) Para conferir se deu certo, após a execução do comando anterior, execute os comando abaixo df -h | grep media No comando acima deverá aparecer a montagem do disco. Se montar deverá aparecer algo. Parabéns, deu certo, se não ver nada...vamos chorar...rsrs ls /media/hd No comando acima deverá aparecer os arquivos do HD externo, caso tenha. Posta aí os resultados depois, ok! Até mais -- Kleber Melo Admin. Sistemas Linux Advanced Level - Linux Professional Institute Certificate (LPIC-2) Novell Certified Linux Administrator (CLA) Novell Data Center Technical Specialist (DCT) Skype: kleber.melo
Re: problema nas permissões
Ola Apenas para constar na sua lista de repositórios (/etc/apt/sources.list) existe as categorias contrib non-free depois de main? E quais repositórios estão na lista? Abraços 2012/12/3 Angela Ferreira angehisto...@hotmail.com Olá Kleber, obrigada pela atenção, mas infelizmente quando tento instalar aptitude install ntfs-3g ntfsprogs diz que o programa n pode ser instalado: nenhum pacote será instalado, atualizado ou removido. 0 pacotes atualizados, 0 novos instalados, 0 a serem removidos e 3 não atualizados. É preciso obter 0 B de arquivos. Depois do desempacotamento, 0 B serão usados. Continuei os passos seguintes mas não obtive sucesso. Nao apareceu nada quando inseri os comandos 7 e 8... Visualizei que o HD externo não é mais reconhecido mesmo conectado. Antes conseguia visualiza-lo no dolphin com uma msg de erro. :( Muitissimo obrigada pela atenção! Angela -- Date: Sun, 2 Dec 2012 23:02:53 -0200 From: kleber...@yahoo.com.br To: angehisto...@hotmail.com CC: adrian...@gmail.com; debian-user-portuguese@lists.debian.org Subject: Re: problema nas permissões Boa noite! Provavelmente você não tem o pacote de aplicativos padrão para o NTFS. Faça o seguinte: 1) Abra um Terminal *Menu Aplicativos - Acessórios - Terminal* 2) Mude para o usuário root (administrador), digitando o comando a seguir e colocando a senha (ao digitar, não aparecerá nenhum digito) *su -* 3) Copie e cole o comando abaixo echo deb http://ftp.debian.org/debian stable main contrib non-free /etc/apt/sources.list 4) Atualize a lista de pacotes de aplicativos do sistema aptitude update 5) Instale os programas abaixo aptitude install ntfs-3g ntfsprogs 6) Coloque seu usuário nos grupos abaixo adduser angela plugdev 7) Tente colocar o HD externo na porta USB, deverá abrir automaticamente. Caso não funcione, execute, ainda como root (Administrador) o comando abaixo (pode copiar/colar) mkdir /media/hd mount -t ntfs-3g */dev/sdb1* /media/hd Obs: O que está em negrito é a partição do seu HD externo. Desta forma entendemos que você tem um HD no sistema, chamado de /dev/sda1 e que o HD externo será o segundo disco. Caso você tenha mais HD's no sistema, é mudar o sdb1 para sd*c*1, sd*d*1, etc 8) Para conferir se deu certo, após a execução do comando anterior, execute os comando abaixo df -h | grep media No comando acima deverá aparecer a montagem do disco. Se montar deverá aparecer algo. Parabéns, deu certo, se não ver nada...vamos chorar...rsrs ls /media/hd No comando acima deverá aparecer os arquivos do HD externo, caso tenha. Posta aí os resultados depois, ok! Até mais -- Kleber Melo Admin. Sistemas Linux Advanced Level - Linux Professional Institute Certificate (LPIC-2) Novell Certified Linux Administrator (CLA) Novell Data Center Technical Specialist (DCT) Skype: kleber.melo
RE: problema nas permissões
Olá Então, minha sourceslist está assim: # # deb cdrom:[Debian GNU/Linux 6.0.6 _Squeeze_ - Official i386 NETINST Binary-1 20120930-15:55]/ squeeze main #deb cdrom:[Debian GNU/Linux 6.0.6 _Squeeze_ - Official i386 NETINST Binary-1 20120930-15:55]/ squeeze main deb http://ftp.br.debian.org/debian/ squeeze main deb-src http://ftp.br.debian.org/debian/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-updates, previously known as 'volatile' deb http://ftp.br.debian.org/debian/ squeeze-updates main deb-src http://ftp.br.debian.org/debian/ squeeze-updates main # squeeze non-free deb http://ftp.br.debian.org/debian/ squeeze main contrib non-free deb-src http://ftp.br.debian.org/debian squeeze main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free deb http://ftp.debian.org/debian stable main contrib non-free :) Angela Date: Mon, 3 Dec 2012 01:14:23 -0200 Subject: Re: problema nas permissões From: professorques...@gmail.com To: angehisto...@hotmail.com CC: kleber...@yahoo.com.br; debian-user-portuguese@lists.debian.org Ola Apenas para constar na sua lista de repositórios (/etc/apt/sources.list)existe as categorias contrib non-free depois de main? E quais repositórios estão na lista? Abraços 2012/12/3 Angela Ferreira angehisto...@hotmail.com Olá Kleber, obrigada pela atenção, mas infelizmente quando tento instalar aptitude install ntfs-3g ntfsprogs diz que o programa n pode ser instalado: nenhum pacote será instalado, atualizado ou removido. 0 pacotes atualizados, 0 novos instalados, 0 a serem removidos e 3 não atualizados. É preciso obter 0 B de arquivos. Depois do desempacotamento, 0 B serão usados. Continuei os passos seguintes mas não obtive sucesso. Nao apareceu nada quando inseri os comandos 7 e 8... Visualizei que o HD externo não é mais reconhecido mesmo conectado. Antes conseguia visualiza-lo no dolphin com uma msg de erro. :( Muitissimo obrigada pela atenção! Angela Date: Sun, 2 Dec 2012 23:02:53 -0200 From: kleber...@yahoo.com.br To: angehisto...@hotmail.com CC: adrian...@gmail.com; debian-user-portuguese@lists.debian.org Subject: Re: problema nas permissões Boa noite! Provavelmente você não tem o pacote de aplicativos padrão para o NTFS. Faça o seguinte: 1) Abra um Terminal Menu Aplicativos - Acessórios - Terminal 2) Mude para o usuário root (administrador), digitando o comando a seguir e colocando a senha (ao digitar, não aparecerá nenhum digito) su - 3) Copie e cole o comando abaixo echo deb http://ftp.debian.org/debian stable main contrib non-free /etc/apt/sources.list 4) Atualize a lista de pacotes de aplicativos do sistema aptitude update 5) Instale os programas abaixo aptitude install ntfs-3g ntfsprogs 6) Coloque seu usuário nos grupos abaixo adduser angela plugdev 7) Tente colocar o HD externo na porta USB, deverá abrir automaticamente. Caso não funcione, execute, ainda como root (Administrador) o comando abaixo (pode copiar/colar) mkdir /media/hd mount -t ntfs-3g /dev/sdb1 /media/hd Obs: O que está em negrito é a partição do seu HD externo. Desta forma entendemos que você tem um HD no sistema, chamado de /dev/sda1 e que o HD externo será o segundo disco. Caso você tenha mais HD's no sistema, é mudar o sdb1 para sdc1, sdd1, etc 8) Para conferir se deu certo, após a execução do comando anterior, execute os comando abaixo df -h | grep media No comando acima deverá aparecer a montagem do disco. Se montar deverá aparecer algo. Parabéns, deu certo, se não ver nada...vamos chorar...rsrs ls /media/hd No comando acima deverá aparecer os arquivos do HD externo, caso tenha. Posta aí os resultados depois, ok! Até mais -- Kleber Melo Admin. Sistemas Linux Advanced Level - Linux Professional Institute Certificate (LPIC-2) Novell Certified Linux Administrator (CLA) Novell Data Center Technical Specialist (DCT) Skype: kleber.melo
Dispositivo não efetiva permissões
Olá pessoal, Estou a Raspberry Pi para comunicar-se com dispositivos eletrônicos através da interface SPI. Então habilitei os dispositivos /dev/spidev* e atribui um grupo com permissão para acesso. Porem, ao reiniciar a rPi, acontece de perder as atribuições que eu tinha dado ao dispositivo. Uma vez precisei criar uma regra Udev para mapaear um dispositivo, mas nesse caso não estou conseguindo fazer o mesmo. Alguem tem ideia de como fazer? Abraço, John
Alterar permissões de arquivos e diretorios
Pessoal, eu to com um problema, eu tenho um diretório que
possui inúmeros arquivos e subdiretórios, e eu preciso alterar as
permissões dos arquivo para o valor 644 e dos diretórios para 755 mas não
consegui fazer essa alteração de forma simples, alguém tem uma dica??
Para os arquivo em php eu consegui fazer isso, mas eu não sei as extensões
de todos os arquivos que estão nesse diretório, por isso dessa forma não
resolve o problema.
find . -name *.php -exec chmod 644 {} \;
Adonai
Re: Alterar permissões de arquivos e diretorios
Em Sun, 24 Jun 2012 21:25:59 -0300
Adonai Silveira Canez adonaica...@gmail.com escreveu:
find . -name *.php -exec chmod 644 {} \;
Tente:
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
signature.asc
Description: PGP signature
Res: Alterar permissões de arquivos e diretorios
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
f de file, d de directory, e assim por diante. Man find.
[]'s
Henry
Enviado pelo meu aparelho BlackBerry® da Vivo
-Original Message-
From: Adonai Silveira Canez adonaica...@gmail.com
Date: Sun, 24 Jun 2012 21:25:59
To: debian-user-portuguese@lists.debian.org
Subject: Alterar permissões de arquivos e diretorios
Pessoal, eu to com um problema, eu tenho um diretório que
possui inúmeros arquivos e subdiretórios, e eu preciso alterar as
permissões dos arquivo para o valor 644 e dos diretórios para 755 mas não
consegui fazer essa alteração de forma simples, alguém tem uma dica??
Para os arquivo em php eu consegui fazer isso, mas eu não sei as extensões
de todos os arquivos que estão nesse diretório, por isso dessa forma não
resolve o problema.
find . -name *.php -exec chmod 644 {} \;
Adonai
Re: Permissões de usuários.
Mas o usuário _precisa_ ter acesso de leitura à raiz ... Caso contrário, como vai acessar o restante do sistema (já que tudo está na raiz). O que um usuário comum não pode ter é acesso de *gravação* à raiz ... Fabiano Pires http://pragasdigitais.blogspot.com/ Em 7 de novembro de 2011 17:42, Cleber Ianes cleberia...@yahoo.com.brescreveu: Saudações. Estou lutando para configurar de forma eficiente um servidor LTSP. No momento meu problema é: O usuário se loga normalmente, mas quando ele abre o navegador de arquivos, além da pasta home, aparece também o ícone para ele acessar o raíz, além de que se ele digitar / no barra de endereço ele consegue acesso a essa pasta e algumas subpastas (como a /opt, por exemplo) eu já defini as pastas de usuários com permissões 700 para que um usuário não tenha acesso a pasta do outro, mas ter acesso ao raíz é bem mais preocupante. Alguém pode me ajudar Obrigado.
Re: Permissões de usuários.
você pode verificar os grupos do seu usuário com $groups nome_do_usuario Caso ele esteja fazendo parte de algum grupo referente às permissões root, tem algo a ser mudado. Você pode pensar na possibilidade de retirar acesso à leitura da sua raiz. Por padrão, o / será drwxr-xr-x Isso quer dizer que o usuário (e todo usuário que pertencer ao grupo users) pode executar e ler, os outros podem somente executar. Sugiro você dar uma lida no foca linux [1], capítulos 11 e 19, pode te ajudar em algumas coisas. Abraço, [1] http://www.jsbusiness.com.br/foca/iniciante/ch-perm.htm *Arnaldo D'Amaral Pereira Granja Russo* Lab. de Estudos dos Oceanos e Clima Instituto de Oceanografia Universidade Federal do Rio Grande e-mail arnaldorusso [at] gmail [dot] com tel (53) 3233-6855 Em 8 de novembro de 2011 23:24, Cleber Ianes cleberia...@yahoo.com.brescreveu: Arnaldo, pode ser mais específico??? O que o grupo afetaria??? Cada usuário está só em seu próprio grupo, por enquanto. Obrigado. Em 08-11-2011 11:52, Arnaldo Russo escreveu: Talvez isso esteja relacionado ao grupo que os usuários pertencem. Já deu uma olhada nisso? Abraço *Arnaldo D'Amaral Pereira Granja Russo* Lab. de Estudos dos Oceanos e Clima Instituto de Oceanografia Universidade Federal do Rio Grande e-mail arnaldorusso [at] gmail [dot] com tel (53) 3233-6855 Em 7 de novembro de 2011 17:42, Cleber Ianes cleberia...@yahoo.com.brescreveu: Saudações. Estou lutando para configurar de forma eficiente um servidor LTSP. No momento meu problema é: O usuário se loga normalmente, mas quando ele abre o navegador de arquivos, além da pasta home, aparece também o ícone para ele acessar o raíz, além de que se ele digitar / no barra de endereço ele consegue acesso a essa pasta e algumas subpastas (como a /opt, por exemplo) eu já defini as pastas de usuários com permissões 700 para que um usuário não tenha acesso a pasta do outro, mas ter acesso ao raíz é bem mais preocupante. Alguém pode me ajudar Obrigado. -- Cleber Ianescleberianes.blogspot.com -- Linux User #507338
Re: Permissões de usuários.
Talvez isso esteja relacionado ao grupo que os usuários pertencem. Já deu uma olhada nisso? Abraço *Arnaldo D'Amaral Pereira Granja Russo* Lab. de Estudos dos Oceanos e Clima Instituto de Oceanografia Universidade Federal do Rio Grande e-mail arnaldorusso [at] gmail [dot] com tel (53) 3233-6855 Em 7 de novembro de 2011 17:42, Cleber Ianes cleberia...@yahoo.com.brescreveu: Saudações. Estou lutando para configurar de forma eficiente um servidor LTSP. No momento meu problema é: O usuário se loga normalmente, mas quando ele abre o navegador de arquivos, além da pasta home, aparece também o ícone para ele acessar o raíz, além de que se ele digitar / no barra de endereço ele consegue acesso a essa pasta e algumas subpastas (como a /opt, por exemplo) eu já defini as pastas de usuários com permissões 700 para que um usuário não tenha acesso a pasta do outro, mas ter acesso ao raíz é bem mais preocupante. Alguém pode me ajudar Obrigado.
Re: Permissões de usuários.
Arnaldo, pode ser mais específico??? O que o grupo afetaria??? Cada usuário está só em seu próprio grupo, por enquanto. Obrigado. Em 08-11-2011 11:52, Arnaldo Russo escreveu: Talvez isso esteja relacionado ao grupo que os usuários pertencem. Já deu uma olhada nisso? Abraço Arnaldo D'Amaral Pereira Granja Russo Lab. de Estudos dos Oceanos e Clima Instituto de Oceanografia Universidade Federal do Rio Grande e-mail arnaldorusso [at] gmail [dot] com tel (53) 3233-6855 Em 7 de novembro de 2011 17:42, Cleber Ianes cleberia...@yahoo.com.br escreveu: Saudações. Estou lutando para configurar de forma eficiente um servidor LTSP. No momento meu problema é: O usuário se loga normalmente, mas quando ele abre o navegador de arquivos, além da pasta home, aparece também o ícone para ele acessar o raíz, além de que se ele digitar "/" no barra de endereço ele consegue acesso a essa pasta e algumas subpastas (como a /opt, por exemplo) eu já defini as pastas de usuários com permissões 700 para que um usuário não tenha acesso a pasta do outro, mas ter acesso ao raíz é bem mais preocupante. Alguém pode me ajudar Obrigado. -- Cleber Ianes cleberianes.blogspot.com -- Linux User #507338 -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb9d662.9040...@yahoo.com.br
Permissões de usuários.
Saudações. Estou lutando para configurar de forma eficiente um servidor LTSP. No momento meu problema é: O usuário se loga normalmente, mas quando ele abre o navegador de arquivos, além da pasta home, aparece também o ícone para ele acessar o raíz, além de que se ele digitar / no barra de endereço ele consegue acesso a essa pasta e algumas subpastas (como a /opt, por exemplo) eu já defini as pastas de usuários com permissões 700 para que um usuário não tenha acesso a pasta do outro, mas ter acesso ao raíz é bem mais preocupante. Alguém pode me ajudar Obrigado.
Re: permissões de arquivo.
veja com quais opções o drive foi montado. Dúvidas? Maiores detalhes ? man mount José de Figueiredo wrote: Linuser, entendo... mas considere que o Debian é uma distribuição que preza muito pela segurança... acredito que esta seja uma diretiva de segurança. t+ Em Qui, 2010-11-04 às 19:45 +0100, linuser escreveu: Prezados, Deparei-me com um problema aparentemente simples, mas sem explicação até agora. Ocorre que não consigo mudar as permissões de um arquivo num drive usb formatado com Vfat. Vejam o arquivo: # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh Agora, como root, # chmod 755 bootinst.sh # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh As permissões não foram alteradas. Eu consigo copiar, criar, apagar arquivos no dispositivo usb. Eu consigo formatar o dispositivo (como root, claro). Eu posso tudo, menos mudar as permissões do arquivo. Já tentei copiar o arquivo para minha home-area, mudar as permissões (dá certo), apagar o arquivo no usb, remover o usb, copiar o arquivo de volta. Resultado: as permissões estão lá, inalteradas! Já tentei formatar o usb como ext3. Neste caso, consegui mudar as permissões, mas alguma outra coisa deu errado (não me lembro agora, após tantas horas). Eu preciso deste arquivo bootinst.sh como executável para tornar o usb bootável. Precisa ser especificamente com este arquivo, devido uma aplicação específica (OpenFoam) que vou rodar. Em tempo: há vários outros arquivos com permissão 'x' no dispositivo. Uso o Squeeze. Idéias? Paulo. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd42bdd.9080...@gmail.com
Re: permissões de arquivo.
Ocorreu o mesmo comigo, o sistema montava o meu pendrive como somente leitura, nem o root conseguia escrever. No entanto, era só com um pendrive específico, todos os outros funcionavam perfeitamente. Solucionei formatando o pendrive, daí passou a montá-lo com permissão de escrita. Para formatar: mkfs.vfat -n NOME_DO_PENDRIVE /dev/sdXY (x = dispositivo e Y = partição, provavelmente X=c e Y=1) On 11/05/2010 02:07 PM, Molinero wrote: veja com quais opções o drive foi montado. Dúvidas? Maiores detalhes ? man mount José de Figueiredo wrote: Linuser, entendo... mas considere que o Debian é uma distribuição que preza muito pela segurança... acredito que esta seja uma diretiva de segurança. t+ Em Qui, 2010-11-04 às 19:45 +0100, linuser escreveu: Prezados, Deparei-me com um problema aparentemente simples, mas sem explicação até agora. Ocorre que não consigo mudar as permissões de um arquivo num drive usb formatado com Vfat. Vejam o arquivo: # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh Agora, como root, # chmod 755 bootinst.sh # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh As permissões não foram alteradas. Eu consigo copiar, criar, apagar arquivos no dispositivo usb. Eu consigo formatar o dispositivo (como root, claro). Eu posso tudo, menos mudar as permissões do arquivo. Já tentei copiar o arquivo para minha home-area, mudar as permissões (dá certo), apagar o arquivo no usb, remover o usb, copiar o arquivo de volta. Resultado: as permissões estão lá, inalteradas! Já tentei formatar o usb como ext3. Neste caso, consegui mudar as permissões, mas alguma outra coisa deu errado (não me lembro agora, após tantas horas). Eu preciso deste arquivo bootinst.sh como executável para tornar o usb bootável. Precisa ser especificamente com este arquivo, devido uma aplicação específica (OpenFoam) que vou rodar. Em tempo: há vários outros arquivos com permissão 'x' no dispositivo. Uso o Squeeze. Idéias? Paulo. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd42d97.70...@gmail.com
permissões de arquivo.
Prezados, Deparei-me com um problema aparentemente simples, mas sem explicação até agora. Ocorre que não consigo mudar as permissões de um arquivo num drive usb formatado com Vfat. Vejam o arquivo: # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh Agora, como root, # chmod 755 bootinst.sh # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh As permissões não foram alteradas. Eu consigo copiar, criar, apagar arquivos no dispositivo usb. Eu consigo formatar o dispositivo (como root, claro). Eu posso tudo, menos mudar as permissões do arquivo. Já tentei copiar o arquivo para minha home-area, mudar as permissões (dá certo), apagar o arquivo no usb, remover o usb, copiar o arquivo de volta. Resultado: as permissões estão lá, inalteradas! Já tentei formatar o usb como ext3. Neste caso, consegui mudar as permissões, mas alguma outra coisa deu errado (não me lembro agora, após tantas horas). Eu preciso deste arquivo bootinst.sh como executável para tornar o usb bootável. Precisa ser especificamente com este arquivo, devido uma aplicação específica (OpenFoam) que vou rodar. Em tempo: há vários outros arquivos com permissão 'x' no dispositivo. Uso o Squeeze. Idéias? Paulo. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101104194506.52ca2...@appia
Re: permissões de arquivo.
Linuser Entendo que o sistema de arquivos vfat, correspondente ao FAT, não possui suporte a permissões de arquivos. Por isso vc não consegue mudar as permissões dos arquivos. A pendrive tem esta característica porque é um dispositivo para compartilhamento de arquivos. Então, se vc quer proteger algum arquivo dentro de uma pendrive, precisa mudar o sistema de arquivos deste device para ext2, ext3 ou ext4 ou outro do gênero. o problema é que vc perderá a portabilidade deste dispositivo. é isso. Em Qui, 2010-11-04 às 19:45 +0100, linuser escreveu: Prezados, Deparei-me com um problema aparentemente simples, mas sem explicação até agora. Ocorre que não consigo mudar as permissões de um arquivo num drive usb formatado com Vfat. Vejam o arquivo: # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh Agora, como root, # chmod 755 bootinst.sh # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh As permissões não foram alteradas. Eu consigo copiar, criar, apagar arquivos no dispositivo usb. Eu consigo formatar o dispositivo (como root, claro). Eu posso tudo, menos mudar as permissões do arquivo. Já tentei copiar o arquivo para minha home-area, mudar as permissões (dá certo), apagar o arquivo no usb, remover o usb, copiar o arquivo de volta. Resultado: as permissões estão lá, inalteradas! Já tentei formatar o usb como ext3. Neste caso, consegui mudar as permissões, mas alguma outra coisa deu errado (não me lembro agora, após tantas horas). Eu preciso deste arquivo bootinst.sh como executável para tornar o usb bootável. Precisa ser especificamente com este arquivo, devido uma aplicação específica (OpenFoam) que vou rodar. Em tempo: há vários outros arquivos com permissão 'x' no dispositivo. Uso o Squeeze. Idéias? Paulo. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1288898426.7136.11.ca...@phoneutria
Re: permissões de arquivo.
Concordo, Figueiredo, que o sistema FAT não contém permissões. Aliás, fazendo alguns testes, pareceu-me que as permissões lá existentes provém da extensão do arquivo (se criar um arquivo .bat, por exemplo, ele aparece como executável). Porém, o fato é que várias pessoas do meu grupo, com exatamente o mesmo conteudo em seu pendrive, mas com outras distribuições linux, conseguiram rodar # ./bootinst.sh e tornar o pen drive inicializável. Eu, porém, em meu lindo Debian (o único no grupo), consigo apenas a mensagem bash: ./bootinst.sh: Permission denied Bem, isso é frustrante, porque perdi horas de trabalho simplesmente porque meu Debian/Squeeze, por algum motivo até agora desconhecido, não me permite fazer algo que uma Suse faz naturalmente. É isso. Obrigado pelos esclarecimentos. Paulo. On Thu, 04 Nov 2010 17:20:26 -0200 José de Figueiredo deb.gnuli...@gmail.com wrote: Linuser Entendo que o sistema de arquivos vfat, correspondente ao FAT, não possui suporte a permissões de arquivos. Por isso vc não consegue mudar as permissões dos arquivos. A pendrive tem esta característica porque é um dispositivo para compartilhamento de arquivos. Então, se vc quer proteger algum arquivo dentro de uma pendrive, precisa mudar o sistema de arquivos deste device para ext2, ext3 ou ext4 ou outro do gênero. o problema é que vc perderá a portabilidade deste dispositivo. é isso. Em Qui, 2010-11-04 às 19:45 +0100, linuser escreveu: Prezados, Deparei-me com um problema aparentemente simples, mas sem explicação até agora. Ocorre que não consigo mudar as permissões de um arquivo num drive usb formatado com Vfat. Vejam o arquivo: # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh Agora, como root, # chmod 755 bootinst.sh # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh As permissões não foram alteradas. Eu consigo copiar, criar, apagar arquivos no dispositivo usb. Eu consigo formatar o dispositivo (como root, claro). Eu posso tudo, menos mudar as permissões do arquivo. Já tentei copiar o arquivo para minha home-area, mudar as permissões (dá certo), apagar o arquivo no usb, remover o usb, copiar o arquivo de volta. Resultado: as permissões estão lá, inalteradas! Já tentei formatar o usb como ext3. Neste caso, consegui mudar as permissões, mas alguma outra coisa deu errado (não me lembro agora, após tantas horas). Eu preciso deste arquivo bootinst.sh como executável para tornar o usb bootável. Precisa ser especificamente com este arquivo, devido uma aplicação específica (OpenFoam) que vou rodar. Em tempo: há vários outros arquivos com permissão 'x' no dispositivo. Uso o Squeeze. Idéias? Paulo. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101104214051.45457...@appia
Re: permissões de arquivo.
Linuser, entendo... mas considere que o Debian é uma distribuição que preza muito pela segurança... acredito que esta seja uma diretiva de segurança. t+ Em Qui, 2010-11-04 às 19:45 +0100, linuser escreveu: Prezados, Deparei-me com um problema aparentemente simples, mas sem explicação até agora. Ocorre que não consigo mudar as permissões de um arquivo num drive usb formatado com Vfat. Vejam o arquivo: # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh Agora, como root, # chmod 755 bootinst.sh # ls -l bootinst.sh -rw-r--r-- 1 manomano2292 Nov 4 19:21 bootinst.sh As permissões não foram alteradas. Eu consigo copiar, criar, apagar arquivos no dispositivo usb. Eu consigo formatar o dispositivo (como root, claro). Eu posso tudo, menos mudar as permissões do arquivo. Já tentei copiar o arquivo para minha home-area, mudar as permissões (dá certo), apagar o arquivo no usb, remover o usb, copiar o arquivo de volta. Resultado: as permissões estão lá, inalteradas! Já tentei formatar o usb como ext3. Neste caso, consegui mudar as permissões, mas alguma outra coisa deu errado (não me lembro agora, após tantas horas). Eu preciso deste arquivo bootinst.sh como executável para tornar o usb bootável. Precisa ser especificamente com este arquivo, devido uma aplicação específica (OpenFoam) que vou rodar. Em tempo: há vários outros arquivos com permissão 'x' no dispositivo. Uso o Squeeze. Idéias? Paulo. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1288915548.7136.19.ca...@phoneutria
Re: Rsync vs Permissões
Acabei usando com o daemon mesmo Mas é uma boa idéia esta da ACL. abraços Em 27 de maio de 2010 11:15, Catulo Hansen catu...@gmail.com escreveu: Em 27 de maio de 2010 10:54, Rafael Moraes raf...@bsd.com.br escreveu: pensei nissomas a politica tb nao permite isso hehe Em 27 de maio de 2010 00:44, Rodolfo Stangherlin rodolf...@gmail.com escreveu: Olá, Você pode rodar o rsync como um usuário com permissão de escrita nos diretórios (root ou um outro, desde que vc dê permissões para o dono ou o grupo) e liberar ssh com um usuário que tenha apenas permissão de leitura no diretório do apache. Nessa solução, a máquina que vai receber os arquivos chama o rsync (vc vai puxar os arquivos, ao invés de enviar). Por exemplo, para copiar da máquina remota para a máquina atual: rsync -av user@origem:/etc/apache2 /etc/apache2 Isso copiaria da máquina origem para a atual (vc usaria o root pra rodar o rsync e o user pra fazer ssh). -- Rodolfo 2010/5/26 hamacker sirhamac...@gmail.com: Olha, se você não pode levar os arquivos até a pasta do usuário então porque não leva para uma outra pasta onde possa grava-los ? Daí você cria um link simbolico na pasta desse usuário apontando para essa pasta), tudo fica transparente. Em 26 de maio de 2010 16:01, Rafael Moraes raf...@bsd.com.br escreveu: Fala Hamacker, Tenho erro de permissão quando o arquivo deve ir para um diretório que este usuario nao tem permissao. Sobre o tar.gz eu até fiz um script pra usar desta maneiramantendo permissões e jogando certinho nos diretóriosporém queria usar o rsync por ser mais inteligenteverificar as mudanças e enviar apenas o que mudou ( evitar tráfego desnecessário na rede )... Em 26 de maio de 2010 15:58, hamacker sirhamac...@gmail.com escreveu: Não sei se tem alguma coisa errada do jeito que você faz. Mas aqui quando sincronizo com o rsync ele mantem as mesmas permissoes de origem no destino. É claro que neste caso, se o dono do arquivo é fulano (UID 1001), no outro sistema tambem deverá haver fulano (UID 1001). Uma outra forma é usar o tar.gz, compactado ele mantem todas as permissoes. Em 26 de maio de 2010 15:48, Rafael Moraes raf...@bsd.com.br escreveu: Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Abraços -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinhaod57dacikompxg9_zh1tzeq0hqllson1...@mail.gmail.com -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified Penso, que poderia ter 2 formas de fazer, atendendo as tuas politicas: 1 - o script do rsync mandaria para o /tmp do segundo servidor, e neste servidor teria uma cron que copiaria esses arquivo para seu devido local, atentando para o script aplicar as devidas permissões. 2 - se o filesystem do segundo servidor suportar ACLs, você poderia aplicar permissões extendidas para o usuário que faz o rsync no /etc/apache2. -- - Atencionamente, Catulo Kruuse Hansen LPI000199593 LPIC-2 catulohansen.blogspot.com -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified
Re: Rsync vs Permissões
pensei nissomas a politica tb nao permite isso hehe Em 27 de maio de 2010 00:44, Rodolfo Stangherlin rodolf...@gmail.comescreveu: Olá, Você pode rodar o rsync como um usuário com permissão de escrita nos diretórios (root ou um outro, desde que vc dê permissões para o dono ou o grupo) e liberar ssh com um usuário que tenha apenas permissão de leitura no diretório do apache. Nessa solução, a máquina que vai receber os arquivos chama o rsync (vc vai puxar os arquivos, ao invés de enviar). Por exemplo, para copiar da máquina remota para a máquina atual: rsync -av user@origem:/etc/apache2 /etc/apache2 Isso copiaria da máquina origem para a atual (vc usaria o root pra rodar o rsync e o user pra fazer ssh). -- Rodolfo 2010/5/26 hamacker sirhamac...@gmail.com: Olha, se você não pode levar os arquivos até a pasta do usuário então porque não leva para uma outra pasta onde possa grava-los ? Daí você cria um link simbolico na pasta desse usuário apontando para essa pasta), tudo fica transparente. Em 26 de maio de 2010 16:01, Rafael Moraes raf...@bsd.com.br escreveu: Fala Hamacker, Tenho erro de permissão quando o arquivo deve ir para um diretório que este usuario nao tem permissao. Sobre o tar.gz eu até fiz um script pra usar desta maneiramantendo permissões e jogando certinho nos diretóriosporém queria usar o rsync por ser mais inteligenteverificar as mudanças e enviar apenas o que mudou ( evitar tráfego desnecessário na rede )... Em 26 de maio de 2010 15:58, hamacker sirhamac...@gmail.com escreveu: Não sei se tem alguma coisa errada do jeito que você faz. Mas aqui quando sincronizo com o rsync ele mantem as mesmas permissoes de origem no destino. É claro que neste caso, se o dono do arquivo é fulano (UID 1001), no outro sistema tambem deverá haver fulano (UID 1001). Uma outra forma é usar o tar.gz, compactado ele mantem todas as permissoes. Em 26 de maio de 2010 15:48, Rafael Moraes raf...@bsd.com.br escreveu: Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Abraços -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinhaod57dacikompxg9_zh1tzeq0hqllson1...@mail.gmail.com -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified
Re: Rsync vs Permissões
Em 27 de maio de 2010 10:54, Rafael Moraes raf...@bsd.com.br escreveu: pensei nissomas a politica tb nao permite isso hehe Em 27 de maio de 2010 00:44, Rodolfo Stangherlin rodolf...@gmail.com escreveu: Olá, Você pode rodar o rsync como um usuário com permissão de escrita nos diretórios (root ou um outro, desde que vc dê permissões para o dono ou o grupo) e liberar ssh com um usuário que tenha apenas permissão de leitura no diretório do apache. Nessa solução, a máquina que vai receber os arquivos chama o rsync (vc vai puxar os arquivos, ao invés de enviar). Por exemplo, para copiar da máquina remota para a máquina atual: rsync -av user@origem:/etc/apache2 /etc/apache2 Isso copiaria da máquina origem para a atual (vc usaria o root pra rodar o rsync e o user pra fazer ssh). -- Rodolfo 2010/5/26 hamacker sirhamac...@gmail.com: Olha, se você não pode levar os arquivos até a pasta do usuário então porque não leva para uma outra pasta onde possa grava-los ? Daí você cria um link simbolico na pasta desse usuário apontando para essa pasta), tudo fica transparente. Em 26 de maio de 2010 16:01, Rafael Moraes raf...@bsd.com.br escreveu: Fala Hamacker, Tenho erro de permissão quando o arquivo deve ir para um diretório que este usuario nao tem permissao. Sobre o tar.gz eu até fiz um script pra usar desta maneiramantendo permissões e jogando certinho nos diretóriosporém queria usar o rsync por ser mais inteligenteverificar as mudanças e enviar apenas o que mudou ( evitar tráfego desnecessário na rede )... Em 26 de maio de 2010 15:58, hamacker sirhamac...@gmail.com escreveu: Não sei se tem alguma coisa errada do jeito que você faz. Mas aqui quando sincronizo com o rsync ele mantem as mesmas permissoes de origem no destino. É claro que neste caso, se o dono do arquivo é fulano (UID 1001), no outro sistema tambem deverá haver fulano (UID 1001). Uma outra forma é usar o tar.gz, compactado ele mantem todas as permissoes. Em 26 de maio de 2010 15:48, Rafael Moraes raf...@bsd.com.br escreveu: Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Abraços -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinhaod57dacikompxg9_zh1tzeq0hqllson1...@mail.gmail.com -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified Penso, que poderia ter 2 formas de fazer, atendendo as tuas politicas: 1 - o script do rsync mandaria para o /tmp do segundo servidor, e neste servidor teria uma cron que copiaria esses arquivo para seu devido local, atentando para o script aplicar as devidas permissões. 2 - se o filesystem do segundo servidor suportar ACLs, você poderia aplicar permissões extendidas para o usuário que faz o rsync no /etc/apache2. -- - Atencionamente, Catulo Kruuse Hansen LPI000199593 LPIC-2 catulohansen.blogspot.com -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktins-ls21caerfnsyiklpiui7xf2jmzzzsw_w...@mail.gmail.com
Rsync vs Permissões
Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Abraços -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified
Re: Rsync vs Permissões
Não sei se tem alguma coisa errada do jeito que você faz. Mas aqui quando sincronizo com o rsync ele mantem as mesmas permissoes de origem no destino. É claro que neste caso, se o dono do arquivo é fulano (UID 1001), no outro sistema tambem deverá haver fulano (UID 1001). Uma outra forma é usar o tar.gz, compactado ele mantem todas as permissoes. Em 26 de maio de 2010 15:48, Rafael Moraes raf...@bsd.com.br escreveu: Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Abraços -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiktke59d7kqxdp4ngyniswtj-fmfbjikxywk...@mail.gmail.com
Re: Rsync vs Permissões
Fala Hamacker, Tenho erro de permissão quando o arquivo deve ir para um diretório que este usuario nao tem permissao. Sobre o tar.gz eu até fiz um script pra usar desta maneiramantendo permissões e jogando certinho nos diretóriosporém queria usar o rsync por ser mais inteligenteverificar as mudanças e enviar apenas o que mudou ( evitar tráfego desnecessário na rede )... Em 26 de maio de 2010 15:58, hamacker sirhamac...@gmail.com escreveu: Não sei se tem alguma coisa errada do jeito que você faz. Mas aqui quando sincronizo com o rsync ele mantem as mesmas permissoes de origem no destino. É claro que neste caso, se o dono do arquivo é fulano (UID 1001), no outro sistema tambem deverá haver fulano (UID 1001). Uma outra forma é usar o tar.gz, compactado ele mantem todas as permissoes. Em 26 de maio de 2010 15:48, Rafael Moraes raf...@bsd.com.br escreveu: Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Abraços -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified
Re: Rsync vs Permissões
--- Em qua, 26/5/10, Rafael Moraes raf...@bsd.com.br escreveu: De: Rafael Moraes raf...@bsd.com.br Assunto: Rsync vs Permissões Para: d-u-p debian-user-portuguese@lists.debian.org Data: Quarta-feira, 26 de Maio de 2010, 15:48 Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Porque não rodar rsync como daemon no host do apache, com isso vc pode, na maquina que irá receber o backup, executar o backup com o usuario que vc quiser. [ ]s, Henry -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/651696.88274...@web113208.mail.gq1.yahoo.com
Re: Rsync vs Permissões
Olha, se você não pode levar os arquivos até a pasta do usuário então porque não leva para uma outra pasta onde possa grava-los ? Daí você cria um link simbolico na pasta desse usuário apontando para essa pasta), tudo fica transparente. Em 26 de maio de 2010 16:01, Rafael Moraes raf...@bsd.com.br escreveu: Fala Hamacker, Tenho erro de permissão quando o arquivo deve ir para um diretório que este usuario nao tem permissao. Sobre o tar.gz eu até fiz um script pra usar desta maneiramantendo permissões e jogando certinho nos diretóriosporém queria usar o rsync por ser mais inteligenteverificar as mudanças e enviar apenas o que mudou ( evitar tráfego desnecessário na rede )... Em 26 de maio de 2010 15:58, hamacker sirhamac...@gmail.com escreveu: Não sei se tem alguma coisa errada do jeito que você faz. Mas aqui quando sincronizo com o rsync ele mantem as mesmas permissoes de origem no destino. É claro que neste caso, se o dono do arquivo é fulano (UID 1001), no outro sistema tambem deverá haver fulano (UID 1001). Uma outra forma é usar o tar.gz, compactado ele mantem todas as permissoes. Em 26 de maio de 2010 15:48, Rafael Moraes raf...@bsd.com.br escreveu: Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Abraços -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinhaod57dacikompxg9_zh1tzeq0hqllson1...@mail.gmail.com
Re: Rsync vs Permissões
Olá, Você pode rodar o rsync como um usuário com permissão de escrita nos diretórios (root ou um outro, desde que vc dê permissões para o dono ou o grupo) e liberar ssh com um usuário que tenha apenas permissão de leitura no diretório do apache. Nessa solução, a máquina que vai receber os arquivos chama o rsync (vc vai puxar os arquivos, ao invés de enviar). Por exemplo, para copiar da máquina remota para a máquina atual: rsync -av user@origem:/etc/apache2 /etc/apache2 Isso copiaria da máquina origem para a atual (vc usaria o root pra rodar o rsync e o user pra fazer ssh). -- Rodolfo 2010/5/26 hamacker sirhamac...@gmail.com: Olha, se você não pode levar os arquivos até a pasta do usuário então porque não leva para uma outra pasta onde possa grava-los ? Daí você cria um link simbolico na pasta desse usuário apontando para essa pasta), tudo fica transparente. Em 26 de maio de 2010 16:01, Rafael Moraes raf...@bsd.com.br escreveu: Fala Hamacker, Tenho erro de permissão quando o arquivo deve ir para um diretório que este usuario nao tem permissao. Sobre o tar.gz eu até fiz um script pra usar desta maneiramantendo permissões e jogando certinho nos diretóriosporém queria usar o rsync por ser mais inteligenteverificar as mudanças e enviar apenas o que mudou ( evitar tráfego desnecessário na rede )... Em 26 de maio de 2010 15:58, hamacker sirhamac...@gmail.com escreveu: Não sei se tem alguma coisa errada do jeito que você faz. Mas aqui quando sincronizo com o rsync ele mantem as mesmas permissoes de origem no destino. É claro que neste caso, se o dono do arquivo é fulano (UID 1001), no outro sistema tambem deverá haver fulano (UID 1001). Uma outra forma é usar o tar.gz, compactado ele mantem todas as permissoes. Em 26 de maio de 2010 15:48, Rafael Moraes raf...@bsd.com.br escreveu: Boa tarde pessoal! vou utilizar o rsync para manter os diretorios /etc/apache2 e mais uns tantos, sincronizados em dois servidores. Entretanto as políticas de segurança não permitem que eu envie como root ou tenha permissão de grupo para qualquer dos diretórios e arquivos de destino. Deste modo, se tento enviar com um usuário comum, mesmo que este esteja nos grupos donos de arquivos e diretorios destino. Soluções gambiarráticas: Colocar o tal user comum com UID e GID 0 - Não pretendo fazer isso, péssima prática Liberar o uso do root pelo ssh - Também não é boa prática Alguma dica? Abraços -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- Att, Rafael Moraes Linux Professional Institute Certified - LPI 2 Novell Certified Linux Administrator - CLA Data Center Technical Specialist - DCTS ITIL Foundations Certified -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinhaod57dacikompxg9_zh1tzeq0hqllson1...@mail.gmail.com -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikcplqaq1ac_abcped_j3_t-e08nvn4adq6e...@mail.gmail.com
Arquivos com permissões corrompidas
Bom dia! Pessoal, já tive esse problema tempos atrás e consegui resolver, mas agora não estou conseguindo lembrar/encontrar os comandos, alguém pode dar uma força aí de como apagar esses arquivos? /var/run# ls -al ls: impossível acessar acpid.pid: Manipulador de arquivo NFS corrompido ls: impossível acessar motd: Manipulador de arquivo NFS corrompido ls: impossível acessar acpid.socket: Manipulador de arquivo NFS corrompido total 96 drwxr-xr-x 14 rootroot4096 Jan 23 10:09 . drwxr-xr-x 14 rootroot4096 Mai 23 2009 .. -? ? ? ? ?? acpid.pid s? ? ? ? ?? acpid.socket -? ? ? ? ?? motd []'s Junior Polegato -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Res: Arquivos com permissões corrompidas
Use o fsck # mount / -o remount,ro # fsck -f / Kléber Leal -- Não à pirataria. Sim ao Software Livre. - Mensagem original De: Junior Polegato - Linux li...@juniorpolegato.com.br Para: Lista de Debian debian-user-portuguese@lists.debian.org Enviadas: Sábado, 23 de Janeiro de 2010 10:06:50 Assunto: Arquivos com permissões corrompidas Bom dia! Pessoal, já tive esse problema tempos atrás e consegui resolver, mas agora não estou conseguindo lembrar/encontrar os comandos, alguém pode dar uma força aí de como apagar esses arquivos? /var/run# ls -al ls: impossível acessar acpid.pid: Manipulador de arquivo NFS corrompido ls: impossível acessar motd: Manipulador de arquivo NFS corrompido ls: impossível acessar acpid.socket: Manipulador de arquivo NFS corrompido total 96 drwxr-xr-x 14 rootroot4096 Jan 23 10:09 . drwxr-xr-x 14 rootroot4096 Mai 23 2009 .. -? ? ? ? ?? acpid.pid s? ? ? ? ?? acpid.socket -? ? ? ? ?? motd []'s Junior Polegato -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problemas com permissões chmod
Em Mon, 11 Jan 2010 23:51:43 -0200 gunix gustavo.gru...@gmail.com escreveu: Porem se eu de uma maquina linux ou até mesmo no serivodr se eu mandar criar um arquivo com o comando toutch e permissão não é dada para o grupo. O grupo fica com direito apenas de leitura, sendo que preciso que fique com permissão gravação. Gunix, tente usar umask 0002. Se quiser aplicar o umask para todos os usuários, talvez você queira ver o man pam_umask. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Problemas com permissões chmod
Galera, tenho um servidor de arquivos, com samba e NFS rodando. Tenho um diretorio comum a um grupo de trabalho e com permissão, 770. drwsrws--- 13 root G_TI 4096 Jan 11 23:33 public_ti Setei o bit +s para que ao gravar o arquivo seja respeitado o grupo do diretorio e nao o grupo principal do usuário. Quanto a isso funciona bem. Porem se eu estiver naestação windows o arquivo na psata é travado corretamente, comn permissão 770. Ex: -rwxrwx--- 1 root G_TI 628168704 Jan 7 16:11 SW_CD_Windows_XP Porem se eu de uma maquina linux ou até mesmo no serivodr se eu mandar criar um arquivo com o comando toutch e permissão não é dada para o grupo. O grupo fica com direito apenas de leitura, sendo que preciso que fique com permissão gravação. ex: -rw-r--r-- 1 gcrocha G_TI0 Jan 11 23:39 teste Desta forma as demias pessoas do grupo não estão conseguindo alterar a permissão do arquivo. Como devo proceder para que a permissão seja dada. Testei = + - s 770 7770 MAs nada funciona. Aguardo quem puder me ajudar. att Gunix
permissões recursivas
Como root criei uma pasta: #mkdir pasta Em seguida mudei a permissão da mesma(inclusive ativando o SGID): #chmod 2775 -R pasta #ls -l drwxrwsr-x 2 root aten 4096 Out 9 17:42 pasta Os arquivos que estão sendo criados dentro dessa pasta estão ficando com permissão assim: #ls -l pasta -rw-rw-r-- 1 van aten 3 Dez 21 11:23 teste7.txt Ele não está ativando o SGID para os arquivos. Já havia feito isso em outras pastas e quando crio arquivos eles ficam assim: -rwxrwsr-x 1 mar aten 16 Dez 21 11:05 xurulepas.txt Alguém sabe o q pode ser?
Re: permissões recursivas
manja tentou ver a questão do grupo ? pode ser que ao tenta criar com um certo usuário ele de esse problematenta criar como root pra ver como que fica 2009/12/21 Célio Roberto celioc...@gmail.com Como root criei uma pasta: #mkdir pasta Em seguida mudei a permissão da mesma(inclusive ativando o SGID): #chmod 2775 -R pasta #ls -l drwxrwsr-x 2 root aten 4096 Out 9 17:42 pasta Os arquivos que estão sendo criados dentro dessa pasta estão ficando com permissão assim: #ls -l pasta -rw-rw-r-- 1 van aten 3 Dez 21 11:23 teste7.txt Ele não está ativando o SGID para os arquivos. Já havia feito isso em outras pastas e quando crio arquivos eles ficam assim: -rwxrwsr-x 1 mar aten 16 Dez 21 11:05 xurulepas.txt Alguém sabe o q pode ser?
Re: [Fwd: permissões incorretas na montagem de hd e xterno]
parabéns ^^ 2009/10/28 Elias Diniz eliasdi...@gmail.com Olá, Consegui resolver. Adicionei ao final do arquivo /etc/fuse.conf adicionei as seguintes linhas: user_allow_other allow_other Depois adicionei meu usuário ao grupo fuse e pronto. Agora o HD externo é montado automaticamente com permissão de escrita para meu usuário. Obrigado pelas sugestões. T+
Re: [Fwd: permissões incorretas na montagem de hd e xterno]
Olá, Consegui resolver. Adicionei ao final do arquivo /etc/fuse.conf adicionei as seguintes linhas: user_allow_other allow_other Depois adicionei meu usuário ao grupo fuse e pronto. Agora o HD externo é montado automaticamente com permissão de escrita para meu usuário. Obrigado pelas sugestões. T+
Re: [Fwd: permissões incorretas na montagem de hd e xterno]
2009/10/26 Elias Diniz eliasdi...@gmail.com: 2009/10/26 Rodolfo rof20...@gmail.com ué.coloca no teu fstab na linha do teu HD a opção users e exec outra forma bem mais simples...é plugar um pendrive que monte automaticamente com escrita e leitura habilitados, depois verificar o arquivo mtab: cat /etc/mtab copia os parametros do pendrive pros do HD no fstab Mas se eu colocar a entrada no fstab, ainda terei que montar manualmente o HD com um mount /dev/sdc1. Acho que, com esta sugestão, o HD vai montar automaticamente no boot. De qualquer jeito, confira se a opção auto está especificada no fstab. abraço, -- ...agora, só nos sobrou o futuro..., visto em www.manuchao.net Gunther Furtado Curitiba - Paraná - Brasil gunfurt...@gmail.com -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Fwd: permissões incorretas na montagem de hd e xterno]
eu te falei pra copiar as entradas de um pendrive que abre automaticamente. 2009/10/26 Elias Diniz eliasdi...@gmail.com 2009/10/26 Rodolfo rof20...@gmail.com ué.coloca no teu fstab na linha do teu HD a opção users e exec outra forma bem mais simples...é plugar um pendrive que monte automaticamente com escrita e leitura habilitados, depois verificar o arquivo mtab: cat /etc/mtab copia os parametros do pendrive pros do HD no fstab Mas se eu colocar a entrada no fstab, ainda terei que montar manualmente o HD com um mount /dev/sdc1.
[Fwd: permissões incorretas na montagem de hd externo]
Talvez isso te ajude: /dev/sdc1 /media/hd ntfs-3g defaults,user 0 0 Repare o parametro user no /etc/fstab Talvez aí seja o lugar mais correto para se colocar o umask tambem. Aqui eu uso assim. Abraço.. -- Lucas Saliés Brum http://sistematico.org lu...@sistematico.org Mensagem encaminhada De: Elias Diniz eliasdi...@gmail.com Para: Lista Debian debian-user-portuguese@lists.debian.org Assunto: permissões incorretas na montagem de hd externo Data: Sun, 25 Oct 2009 22:30:11 -0200 Olá, Uso o SID com Gnome e recentemente ao conectar um HD externo USB o sistema monta automaticamente o disco apenas para leitura. O HD está formatado em ntfs e tenho instalado o ntfs-3g. Se monto o disco manualmente, através de um: mount -t ntfs-3g /dev/sdc1 /media/hd o HD é montado com acesso de leitura e escrita para meu usuário. Alterei a configuração do gnome-mount (através do gconf-editor, em /system/storage/default_options/ntfs/fstype_override ) para montar os discos com umask=020 e forçar a utilização do ntfs-3g como driver padrão. Também já adicionei meu usuário nas permissões do HAL no policykit. Meu usuário está no grupo plugdev. Mesmo depois desses procedimentos, o problema continua. Então, alguma idéia ? signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: permissões incorretas na montagem de hd externo
2009/10/25 henry jmhenri...@yahoo.com.br Em Domingo 25 Outubro 2009, às 22:30:11, Elias Diniz escreveu: Olá, Uso o SID com Gnome e recentemente ao conectar um HD externo USB o sistema monta automaticamente o disco apenas para leitura. O HD está formatado em ntfs e tenho instalado o ntfs-3g. Se monto o disco manualmente, através de um: mount -t ntfs-3g /dev/sdc1 /media/hd o HD é montado com acesso de leitura e escrita para meu usuário. Alterei a configuração do gnome-mount (através do gconf-editor, em /system/storage/default_options/ntfs/fstype_override ) para montar os discos com umask=020 e forçar a utilização do ntfs-3g como driver padrão. Também já adicionei meu usuário nas permissões do HAL no policykit. Meu usuário está no grupo plugdev. Mesmo depois desses procedimentos, o problema continua. Então, alguma idéia ? Olá! umask=002 no lugar de umask=020 ? Ok. Vou tentar mudar o umask. [ ]s, Henry. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Fwd: permissões incorretas na montagem de hd e xterno]
2009/10/26 Lucas Saliés Brum sistemat...@gmail.com Talvez isso te ajude: /dev/sdc1 /media/hd ntfs-3g defaults,user 0 0 Repare o parametro user no /etc/fstab Talvez aí seja o lugar mais correto para se colocar o umask tambem. Aqui eu uso assim. Mas se eu colocar essa linha no Fstab, ainda terei que montar o disco manualmente através de um: mount /dev/sdc1. O que eu quero é que a montagem seja automática. Andei pesquisando mais um pouco e talvez seja uma solução criar um device persistente com o udev[1]. [1] http://tchellomello.blogspot.com/2009/10/criando-devices-persistentes-com-udev.html Mas ainda acredito que o sistema deveria montar o HD com as permissões corretas.
Re: [Fwd: permissões incorretas na montagem de hd e xterno]
ué.coloca no teu fstab na linha do teu HD a opção users e exec outra forma bem mais simples...é plugar um pendrive que monte automaticamente com escrita e leitura habilitados, depois verificar o arquivo mtab: cat /etc/mtab copia os parametros do pendrive pros do HD no fstab 2009/10/26 Elias Diniz eliasdi...@gmail.com 2009/10/26 Lucas Saliés Brum sistemat...@gmail.com Talvez isso te ajude: /dev/sdc1 /media/hd ntfs-3g defaults,user 0 0 Repare o parametro user no /etc/fstab Talvez aí seja o lugar mais correto para se colocar o umask tambem. Aqui eu uso assim. Mas se eu colocar essa linha no Fstab, ainda terei que montar o disco manualmente através de um: mount /dev/sdc1. O que eu quero é que a montagem seja automática. Andei pesquisando mais um pouco e talvez seja uma solução criar um device persistente com o udev[1]. [1] http://tchellomello.blogspot.com/2009/10/criando-devices-persistentes-com-udev.html Mas ainda acredito que o sistema deveria montar o HD com as permissões corretas.
Re: [Fwd: permissões incorretas na montagem de hd e xterno]
aa..ia esquecendo.tem a opção rw pra colocar no fstab tb...da uma tentada...se tiver ro troca por rw 2009/10/26 Rodolfo rof20...@gmail.com ué.coloca no teu fstab na linha do teu HD a opção users e exec outra forma bem mais simples...é plugar um pendrive que monte automaticamente com escrita e leitura habilitados, depois verificar o arquivo mtab: cat /etc/mtab copia os parametros do pendrive pros do HD no fstab 2009/10/26 Elias Diniz eliasdi...@gmail.com 2009/10/26 Lucas Saliés Brum sistemat...@gmail.com Talvez isso te ajude: /dev/sdc1 /media/hd ntfs-3g defaults,user 0 0 Repare o parametro user no /etc/fstab Talvez aí seja o lugar mais correto para se colocar o umask tambem. Aqui eu uso assim. Mas se eu colocar essa linha no Fstab, ainda terei que montar o disco manualmente através de um: mount /dev/sdc1. O que eu quero é que a montagem seja automática. Andei pesquisando mais um pouco e talvez seja uma solução criar um device persistente com o udev[1]. [1] http://tchellomello.blogspot.com/2009/10/criando-devices-persistentes-com-udev.html Mas ainda acredito que o sistema deveria montar o HD com as permissões corretas.
Re: [Fwd: permissões incorretas na montagem de hd e xterno]
2009/10/26 Rodolfo rof20...@gmail.com ué.coloca no teu fstab na linha do teu HD a opção users e exec outra forma bem mais simples...é plugar um pendrive que monte automaticamente com escrita e leitura habilitados, depois verificar o arquivo mtab: cat /etc/mtab copia os parametros do pendrive pros do HD no fstab Mas se eu colocar a entrada no fstab, ainda terei que montar manualmente o HD com um mount /dev/sdc1.
permissões incorretas na montagem de hd externo
Olá, Uso o SID com Gnome e recentemente ao conectar um HD externo USB o sistema monta automaticamente o disco apenas para leitura. O HD está formatado em ntfs e tenho instalado o ntfs-3g. Se monto o disco manualmente, através de um: mount -t ntfs-3g /dev/sdc1 /media/hd o HD é montado com acesso de leitura e escrita para meu usuário. Alterei a configuração do gnome-mount (através do gconf-editor, em /system/storage/default_options/ntfs/fstype_override ) para montar os discos com umask=020 e forçar a utilização do ntfs-3g como driver padrão. Também já adicionei meu usuário nas permissões do HAL no policykit. Meu usuário está no grupo plugdev. Mesmo depois desses procedimentos, o problema continua. Então, alguma idéia ?
Re: permissões incorretas na montagem de hd externo
Em Domingo 25 Outubro 2009, às 22:30:11, Elias Diniz escreveu: Olá, Uso o SID com Gnome e recentemente ao conectar um HD externo USB o sistema monta automaticamente o disco apenas para leitura. O HD está formatado em ntfs e tenho instalado o ntfs-3g. Se monto o disco manualmente, através de um: mount -t ntfs-3g /dev/sdc1 /media/hd o HD é montado com acesso de leitura e escrita para meu usuário. Alterei a configuração do gnome-mount (através do gconf-editor, em /system/storage/default_options/ntfs/fstype_override ) para montar os discos com umask=020 e forçar a utilização do ntfs-3g como driver padrão. Também já adicionei meu usuário nas permissões do HAL no policykit. Meu usuário está no grupo plugdev. Mesmo depois desses procedimentos, o problema continua. Então, alguma idéia ? Olá! umask=002 no lugar de umask=020 ? [ ]s, Henry. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Gnome-ppp - permissões/ Resolvido-
OLá pessoal, Hoje liguei computador e testei o gnome-ppp e funcionou, talvez faltava dar o reboot. Obrigado por tudo. Abraços Marcos. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Permissões Gnome-ppp
Olá pessoal, O link que me ajudaria a resolver meu problema não funciona, está na página http://www.debian.org/doc/manuals/reference/ch-install.pt-br.html. subtópico 3,7,6 - Configurações dialup. Já rodei o comando: usermod -G dialout,tty,dip,audio,video,plugdev,voice,fax,cdrom marcos, mas não consigo permitir que o gnome-ppp seja acionado sem auxílio do root. debian:/home/marcos# groups marcos marcos tty dialout fax voice cdrom audio dip video plugdev debian:/home/marcos# Aguardo esclarecimentos, Abraços, Marcos. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Ajustar PERMISSÕES de usuários DOMÍNI O-SAMBA
Olá galera. Estou configurando um Samba-PDC. Dentro dos Scripts de logon dos usuários, além dos mapeamentos pertencentes a cada um deles, também coloquei um comando para sincronizar a hora com o horário do Servidor: net time \\Servidor /set /yes (sem as aspas). O problema é que ao rodar este comando (net time \\Arquivos /set /yes), mesmo que MANUALMENTE (no prompt do DOS) depois de logado no dóminio dá PERMISSÃO NEGADA. Os compartilhamentos foram normalmente mapeados!!! Como faço para setar as permissões dos usuários num domínio samba? Inlclusive a permissão para ajustar o horário da estação Windows-XP. grato, Flávio -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ajustar PERMISSÕES de usuários DOMÍNIO-SAMBA
Somente usuários avançados (cadastrado nesse grupo) podem alterar a data do sistema. Esse é o modo operacional padrão do Windows. Voce pode resolver de varias maneiras, uma é criando esse grupo no Samba (no samba mesmo, não é o linux). Outra é usar gpedit.msc e dar essa permissão de alterar data/hora à maquina, e qualquer um que logar nela vai poder fazer isso. Outra é ajustar o servidor de hora do windows para sincronizar com algum servidor NTP de sua rede ou da internet. []'s e sucesso. 2009/4/17 Flávio R. Lopes flavio.li...@paradoxo.inf.br: Olá galera. Estou configurando um Samba-PDC. Dentro dos Scripts de logon dos usuários, além dos mapeamentos pertencentes a cada um deles, também coloquei um comando para sincronizar a hora com o horário do Servidor: net time \\Servidor /set /yes (sem as aspas). O problema é que ao rodar este comando (net time \\Arquivos /set /yes), mesmo que MANUALMENTE (no prompt do DOS) depois de logado no dóminio dá PERMISSÃO NEGADA. Os compartilhamentos foram normalmente mapeados!!! Como faço para setar as permissões dos usuários num domínio samba? Inlclusive a permissão para ajustar o horário da estação Windows-XP. grato, Flávio -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problemas permissões de usuários com o Firebir d
Na ferramenta isql dele os comandos são digitados de forma diferente, é a mesma sintaxe, mas as coisas mudam, por exemplo, voce conecta a base primeiro e assim voce nao precisa de database.tabela, afinal voce já está na base. Eu sugiro que voce use programas como o flamerobin para fazer estes tipos de operacoes com o banco. Há um programa chamado Grantrole no sourceforge só para gerenciar permissoes, sejam elas baseadas em usuarios ou em roles. []'s e sucesso. 2009/4/1 yuRi ssjo...@gmail.com: Tentei realizar o comando passado: grant all on DATABASE.TABELA to USER with grant option mas ele nao aceita essa linha de comando. Estou pesquisando as possibilidades e estudando um pouco sobre ROLE para ver se consigo alguma coisa. Obrigado por enquanto 2009/3/31 hamacker sirhamac...@gmail.com Conforme indicado pelos colegas, o comando SQL GRANT é o que garante que usuario A, B ou C tenham acesso as tabelas ou qualquer outro objeto(tabelas,views,procedures,...), a única exceção fica por conta do SYSDBA que é uma conta administrativa que sempre terá acesso a qualquer database que se conecte. Alem das permissões por usuário, há as permissões por ROLE onde é a ROLE e não o usuário que detém as permissões, o usuário é associado a uma ROLE (ele tem de ter direito a ela) no momento da conexão e recebe os direitos que a ROLE possui sobre os objetos, este é um recurso útil para gerenciar usuários e permissões em sistemas mais complexos. []'s e boa sorte. 2009/3/31 yuRi ssjo...@gmail.com: Primeiramente desculpe por estar postando algo que não esta relacionado ao tema principal da lista, sei que estou postando em lista errada, mas se alguém me ajudar serei eternamente grato. Estou com um problema com o Firebird e gostaria de saber se o banco é usado dessa forma. Vamos a um exemplo do problema: Tenho um usuário 'A' e um usuário 'B'. O usuário 'A' cria um database e depois uma tabela dentro desse database, se eu me autentico com o usuário 'B', eu consigo acessar o database criado por A e visualizar as tabelas criadas por ele (não consigo ver os dados inseridos nas tabelas). É possivel barrar que o usuário B acesse esse database de A? Estou acostumado a trabalhar com mysql e sql, e esses banco de dados não permitem que outros usuários acessem a áreas restritas. Se é possivel barrar esses acessos, aonde faço essas configurações? Observação: Estou utilizando Debian e a versão do Firebird é 2.1.1 Obrigado, e desculpe por estar postando em uma lista que não é especialista em Firebird -- ~yuRi -- ~yuRi -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: Problemas permissões de usuários com o Fir ebird
já viu as configuraões de pastas?
Problemas permissões de usuários com o Firebird
tenta atualizar seu firefox
Re: Problemas permissões de usuários com o Firebir d
Obrigado pessoal, vou tentar sim. Estou utilizando o flamerobin, com ele eu consigo arrumar cada usuário do firebird como se fosse um usuário do linux, pois eu consigo definir seu uid e gid. Tentei fazer por permissões no próprio Linux, porém todas as alterações realizadas em arquivo, são realizadas pelo usuário firebird, ou seja, TODOS os usuários do firebird, para o linux, são pertencentes ao grupo firebird. O problema é que as permissões sempre são setadas a partir de tabelas. Até agora não consegui setar por base de dados, mas ainda não perdi a fé, estou estudando esse novo banco para que eu realmente aprenda a gerencia-lo. Sinto que estou no caminho certo. Vou tentar fazer o teste Grantrole, se eu tiver sucesso postaria aqui p/ vocês. Obrigado pela ajuda e por me dar um rumo a seguir. PS: não entendi o firefox 2009/4/2 Rodolfo rof20...@gmail.com tenta atualizar seu firefox -- ~yuRi
Re: Problemas permissões de usuários com o Firebir d
Os usuários do firebird não são cadastrados no Linux, são cadastrados dentro do firebird e nada tem a ver com os usuarios cadastrados no SO. O Firebird mantém um database especial chamado de fbsecurity.fdb que dentre algumas tabelas especiais contém os usuários cadastrados e suas senhas, todo usuário que se conecta ao banco de dados passa por esse database para autenticar-se. Tanto que se voce esquecer a conta do SYSDBA e por causa disso não consegue conectar database a nenhum, basta substituir esse database por outro onde a senha do SYSDBA seja conhecida e pronto tá resolvido o problema, furo de segurança ? Não, este banco de dados baseia sua segurança no Host, ie. o ambiente fisico e SO são responsáveis por prover a segurança dos dados, por exemplo, no Linux o owner dos arquivos do firebird chama-se firebird, isto facilita porque o banco de dados não precisa usar uma conta de root para fazer suas operações com o SO, usuários comuns não conseguem manipular fisicamente os arquivos e impede que falhas do FB sejam escaladas para níveis de privilegio superiores. É um bom banco de dados, mas programadores em delphi tem dificuldade em lidar com transacoes, usam dataawares que ligam componentes de dados a uma unica transacao, ficam o dia inteiro sem fazer um único commit físico e por causa disso enchem a garbage e o banco explode o servidor. Se voce aprender a dominar as tecnicas da boa programação vai ser feliz. []'s e boa sorte. 2009/4/2 yuRi ssjo...@gmail.com: Obrigado pessoal, vou tentar sim. Estou utilizando o flamerobin, com ele eu consigo arrumar cada usuário do firebird como se fosse um usuário do linux, pois eu consigo definir seu uid e gid. Tentei fazer por permissões no próprio Linux, porém todas as alterações realizadas em arquivo, são realizadas pelo usuário firebird, ou seja, TODOS os usuários do firebird, para o linux, são pertencentes ao grupo firebird. O problema é que as permissões sempre são setadas a partir de tabelas. Até agora não consegui setar por base de dados, mas ainda não perdi a fé, estou estudando esse novo banco para que eu realmente aprenda a gerencia-lo. Sinto que estou no caminho certo. Vou tentar fazer o teste Grantrole, se eu tiver sucesso postaria aqui p/ vocês. Obrigado pela ajuda e por me dar um rumo a seguir. PS: não entendi o firefox 2009/4/2 Rodolfo rof20...@gmail.com tenta atualizar seu firefox -- ~yuRi -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problemas permissões de usuários com o Firebir d
Tentei realizar o comando passado: grant all on DATABASE.TABELA to USER with grant option mas ele nao aceita essa linha de comando. Estou pesquisando as possibilidades e estudando um pouco sobre ROLE para ver se consigo alguma coisa. Obrigado por enquanto 2009/3/31 hamacker sirhamac...@gmail.com Conforme indicado pelos colegas, o comando SQL GRANT é o que garante que usuario A, B ou C tenham acesso as tabelas ou qualquer outro objeto(tabelas,views,procedures,...), a única exceção fica por conta do SYSDBA que é uma conta administrativa que sempre terá acesso a qualquer database que se conecte. Alem das permissões por usuário, há as permissões por ROLE onde é a ROLE e não o usuário que detém as permissões, o usuário é associado a uma ROLE (ele tem de ter direito a ela) no momento da conexão e recebe os direitos que a ROLE possui sobre os objetos, este é um recurso útil para gerenciar usuários e permissões em sistemas mais complexos. []'s e boa sorte. 2009/3/31 yuRi ssjo...@gmail.com: Primeiramente desculpe por estar postando algo que não esta relacionado ao tema principal da lista, sei que estou postando em lista errada, mas se alguém me ajudar serei eternamente grato. Estou com um problema com o Firebird e gostaria de saber se o banco é usado dessa forma. Vamos a um exemplo do problema: Tenho um usuário 'A' e um usuário 'B'. O usuário 'A' cria um database e depois uma tabela dentro desse database, se eu me autentico com o usuário 'B', eu consigo acessar o database criado por A e visualizar as tabelas criadas por ele (não consigo ver os dados inseridos nas tabelas). É possivel barrar que o usuário B acesse esse database de A? Estou acostumado a trabalhar com mysql e sql, e esses banco de dados não permitem que outros usuários acessem a áreas restritas. Se é possivel barrar esses acessos, aonde faço essas configurações? Observação: Estou utilizando Debian e a versão do Firebird é 2.1.1 Obrigado, e desculpe por estar postando em uma lista que não é especialista em Firebird -- ~yuRi -- ~yuRi
Re: Problemas permissões de usuários com o Firebir d
Só para exemplificar melhor, Exemplo: grant all on minhatabela to martina with grant option Eu sempre encontro regras relacionadas as tabelas, dessa forma eu consigo que ninguém acesse a tabela ou acesse, etc. Meu problema é que cada usuário possua o seu database e ninguém mais o acesse. Acho que fui mais claro dessa vez. 2009/3/31 yuRi ssjo...@gmail.com Primeiramente desculpe por estar postando algo que não esta relacionado ao tema principal da lista, sei que estou postando em lista errada, mas se alguém me ajudar serei eternamente grato. Estou com um problema com o Firebird e gostaria de saber se o banco é usado dessa forma. Vamos a um exemplo do problema: Tenho um usuário 'A' e um usuário 'B'. O usuário 'A' cria um database e depois uma tabela dentro desse database, se eu me autentico com o usuário 'B', eu consigo acessar o database criado por A e visualizar as tabelas criadas por ele (não consigo ver os dados inseridos nas tabelas). É possivel barrar que o usuário B acesse esse database de A? Estou acostumado a trabalhar com mysql e sql, e esses banco de dados não permitem que outros usuários acessem a áreas restritas. Se é possivel barrar esses acessos, aonde faço essas configurações? Observação: Estou utilizando Debian e a versão do Firebird é 2.1.1 Obrigado, e desculpe por estar postando em uma lista que não é especialista em Firebird -- ~yuRi -- ~yuRi
Problemas permissões de usuários com o Firebird
Primeiramente desculpe por estar postando algo que não esta relacionado ao tema principal da lista, sei que estou postando em lista errada, mas se alguém me ajudar serei eternamente grato. Estou com um problema com o Firebird e gostaria de saber se o banco é usado dessa forma. Vamos a um exemplo do problema: Tenho um usuário 'A' e um usuário 'B'. O usuário 'A' cria um database e depois uma tabela dentro desse database, se eu me autentico com o usuário 'B', eu consigo acessar o database criado por A e visualizar as tabelas criadas por ele (não consigo ver os dados inseridos nas tabelas). É possivel barrar que o usuário B acesse esse database de A? Estou acostumado a trabalhar com mysql e sql, e esses banco de dados não permitem que outros usuários acessem a áreas restritas. Se é possivel barrar esses acessos, aonde faço essas configurações? Observação: Estou utilizando Debian e a versão do Firebird é 2.1.1 Obrigado, e desculpe por estar postando em uma lista que não é especialista em Firebird -- ~yuRi
Re: Problemas permissões de usuários com o Firebir d
2009/3/31 yuRi ssjo...@gmail.com Só para exemplificar melhor, Exemplo: grant all on minhatabela to martina with grant option Eu sempre encontro regras relacionadas as tabelas, dessa forma eu consigo que ninguém acesse a tabela ou acesse, etc. Meu problema é que cada usuário possua o seu database e ninguém mais o acesse. Acho que fui mais claro dessa vez. 2009/3/31 yuRi ssjo...@gmail.com Primeiramente desculpe por estar postando algo que não esta relacionado ao tema principal da lista, sei que estou postando em lista errada, mas se alguém me ajudar serei eternamente grato. Estou com um problema com o Firebird e gostaria de saber se o banco é usado dessa forma. Vamos a um exemplo do problema: Tenho um usuário 'A' e um usuário 'B'. O usuário 'A' cria um database e depois uma tabela dentro desse database, se eu me autentico com o usuário 'B', eu consigo acessar o database criado por A e visualizar as tabelas criadas por ele (não consigo ver os dados inseridos nas tabelas). É possivel barrar que o usuário B acesse esse database de A? Estou acostumado a trabalhar com mysql e sql, e esses banco de dados não permitem que outros usuários acessem a áreas restritas. Se é possivel barrar esses acessos, aonde faço essas configurações? Observação: Estou utilizando Debian e a versão do Firebird é 2.1.1 Obrigado, e desculpe por estar postando em uma lista que não é especialista em Firebird -- ~yuRi -- ~yuRi Genericamente o comando GRANT funciona assim: grant all on banco.tabelas to user with grant option então tente assim: grant all on BancoDaMartina.* to martina with grant option BancoDaMartina.* quer dizer todas as tabelas do banco BancoDaMartina. -- Fabiano Pires LPIC-2 http://pragasdigitais.blogspot.com/ Livrando você da escória da Internet!
Re: Problemas permissões de usuários co m o Firebird
Um bom lugar para tirar esta dvida o site www.firebase.com.br . L tambm tem uma lista de usurios do firebird. Mas o caminho como os colegas disseram o GRANT . Obrigado -- Alexandre Pereira Bhler Linux User: 397.546 Simo Bhler Ltda (Infobrindes) Instalao, manuteno e venda de servidores GNU/Linux. http://www.infobrindes.com.br alexan...@infobrindes.com.br Telefones: (41) 3538-5428 / (41) 3532-5428 Colunista: www.delphisophp.com Owner: http://br.groups.yahoo.com/group/freepascal/ Liberdade essencial. Use GNU/Linux. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Problemas permissões de usuários com o Firebir d
Conforme indicado pelos colegas, o comando SQL GRANT é o que garante que usuario A, B ou C tenham acesso as tabelas ou qualquer outro objeto(tabelas,views,procedures,...), a única exceção fica por conta do SYSDBA que é uma conta administrativa que sempre terá acesso a qualquer database que se conecte. Alem das permissões por usuário, há as permissões por ROLE onde é a ROLE e não o usuário que detém as permissões, o usuário é associado a uma ROLE (ele tem de ter direito a ela) no momento da conexão e recebe os direitos que a ROLE possui sobre os objetos, este é um recurso útil para gerenciar usuários e permissões em sistemas mais complexos. []'s e boa sorte. 2009/3/31 yuRi ssjo...@gmail.com: Primeiramente desculpe por estar postando algo que não esta relacionado ao tema principal da lista, sei que estou postando em lista errada, mas se alguém me ajudar serei eternamente grato. Estou com um problema com o Firebird e gostaria de saber se o banco é usado dessa forma. Vamos a um exemplo do problema: Tenho um usuário 'A' e um usuário 'B'. O usuário 'A' cria um database e depois uma tabela dentro desse database, se eu me autentico com o usuário 'B', eu consigo acessar o database criado por A e visualizar as tabelas criadas por ele (não consigo ver os dados inseridos nas tabelas). É possivel barrar que o usuário B acesse esse database de A? Estou acostumado a trabalhar com mysql e sql, e esses banco de dados não permitem que outros usuários acessem a áreas restritas. Se é possivel barrar esses acessos, aonde faço essas configurações? Observação: Estou utilizando Debian e a versão do Firebird é 2.1.1 Obrigado, e desculpe por estar postando em uma lista que não é especialista em Firebird -- ~yuRi -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problema confuso com NFS e permissões que não funcionam.
Miguel Da Silva - URI escribió: Olha só gente que problema extranho que comcei a ter hoje com um servidor NFS: mdasi...@computador ~ $ mount /dev/sda3 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw) automount(pid2153) on /home type autofs (rw,fd=4,pgrp=2153,minproto=2,maxproto=4) home:/home/cmat on /home/cmat type nfs (rw,nodev,rsize=8192,wsize=8192,bg,intr,addr=192.168.1.5) mdasi...@computador ~ $ pwd /home/cmat/mdasilva mdasi...@computador ~ $ touch mdasilva touch: no se puede efectuar `touch' sobre «mdasilva»: Permiso denegado mdasi...@computador ~ $ id uid=3150(mdasilva) gid=3150(mdasilva) grupos=3150(mdasilva) mdasi...@computador ~ $ ls -ld . drwxr-xr-x 89 mdasilva mdasilva 12K feb 18 22:48 . Pois então, aparentemente o diretório home:/home/cmat está sendo montado em /home/cmat com permissões rw, porém quando um usuário tenta criar um arquivo no seu próprio diretório, recebe um Permiso denegado (o que seria em inglês Permission denied). Já tentei reiniciar o autofs, montar o diretório na mão, etc, etc e o problema continua. sugestões?! Até. Resolvido. Deixo o seguinte link como referência: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970 A opção sec=sys resolveu o problema. Até. -- Miguel Da Silva Unidad de Recursos Informáticos Facultad de Ingeniería - http://www.fing.edu.uy Universidad de la República - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Problema confuso com NFS e permissões que n ão funcionam.
Olha só gente que problema extranho que comcei a ter hoje com um servidor NFS: mdasi...@computador ~ $ mount /dev/sda3 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw) automount(pid2153) on /home type autofs (rw,fd=4,pgrp=2153,minproto=2,maxproto=4) home:/home/cmat on /home/cmat type nfs (rw,nodev,rsize=8192,wsize=8192,bg,intr,addr=192.168.1.5) mdasi...@computador ~ $ pwd /home/cmat/mdasilva mdasi...@computador ~ $ touch mdasilva touch: no se puede efectuar `touch' sobre «mdasilva»: Permiso denegado mdasi...@computador ~ $ id uid=3150(mdasilva) gid=3150(mdasilva) grupos=3150(mdasilva) mdasi...@computador ~ $ ls -ld . drwxr-xr-x 89 mdasilva mdasilva 12K feb 18 22:48 . Pois então, aparentemente o diretório home:/home/cmat está sendo montado em /home/cmat com permissões rw, porém quando um usuário tenta criar um arquivo no seu próprio diretório, recebe um Permiso denegado (o que seria em inglês Permission denied). Já tentei reiniciar o autofs, montar o diretório na mão, etc, etc e o problema continua. sugestões?! Até. -- Miguel Da Silva Unidad de Recursos Informáticos Facultad de Ingeniería - http://www.fing.edu.uy Universidad de la República - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Configurando permissões do samba
Rafael Tomelin escribió: Olá pessoal, Gostaria da ajuda de vocês para configurar um servidor samba de um cliente. Estou usando o samba como controlador de domínio e tenho vários usuários e grupos além dos diretórios. Preciso fazer o seguinte: Vamos dizer que tenho os grupos: users diretoria financeiro contabilidade Usuários rafael - users tomelin - users diretor - diretoria gerente - diretoria fulano - financeiro ciclano - contabilidade Diretório /dados/publico - Aqui todo mundo pode escrever/ler e criar /dados/arquivos - aqui todo mundo pode ler/criar Ou seja, dentro do diretorio /dados/arquivos todo mundo pode criar arquivos novos e ler os arquivos, porém só o grupo diretoria pode alterar os arquivos. Tem como fazer isso? Já tentei assim: [Arquivos] comment = Arquivos path = /dados/arquivos browseable = yes #create mask = 0744 #directory mask = 0744 guest ok = yes writable = yes # force create mode = 0744 # force user = %U # valid users = @diretoria, @financeiro, @users # read list = @diretoria, @financeiro, @users # write list = @diretoria force group = diretoria force user = diretor o que posso fazer? E as permissões no sistema de arquivos destes diretórios permitem/restrigem o acesso do jeito que você quer? Até. -- Miguel Da Silva Administrador Junior de Sistemas Unix Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Configurando permissões do samba
Olá pessoal, Gostaria da ajuda de vocês para configurar um servidor samba de um cliente. Estou usando o samba como controlador de domínio e tenho vários usuários e grupos além dos diretórios. Preciso fazer o seguinte: Vamos dizer que tenho os grupos: users diretoria financeiro contabilidade Usuários rafael - users tomelin - users diretor - diretoria gerente - diretoria fulano - financeiro ciclano - contabilidade Diretório /dados/publico - Aqui todo mundo pode escrever/ler e criar /dados/arquivos - aqui todo mundo pode ler/criar Ou seja, dentro do diretorio /dados/arquivos todo mundo pode criar arquivos novos e ler os arquivos, porém só o grupo diretoria pode alterar os arquivos. Tem como fazer isso? Já tentei assim: [Arquivos] comment = Arquivos path = /dados/arquivos browseable = yes #create mask = 0744 #directory mask = 0744 guest ok = yes writable = yes # force create mode = 0744 # force user = %U # valid users = @diretoria, @financeiro, @users # read list = @diretoria, @financeiro, @users # write list = @diretoria force group = diretoria force user = diretor o que posso fazer?
Re: Herdando Permissões de Pastas e Arquivos
Leandro e Gilberto, Consegui, sua dica foi muito importante pra mim. Finalizei com a dica do Gilberto. Ficou Perfeito. Só o windows que não mostra direito as permissões mais elas estão funcionando. obrigado a todos ! Adauto Serpa. 2008/11/12 Leandro Moreira [EMAIL PROTECTED]: Adauto, No seu caso oq ue vc precisa e do SGID-BIT , assim todos os arquivos e pastas criado no diretório terao o grupo do diretório corrente, caso queira aumnetar a segurança tb pode ativar o STICK-BIT, pois assim so o dono do arquivo ou pasta pode deleta-lo ## SGID-BIT chmod 2755 /diretorio onde 2 é o valor q ativa so SGID-BIT ## STICK-BIT chmod 1755 /diretorio onde 1 é o valor q ativa so SGID-BIT ## SITCK-BIT + SGID-BIT chmod 3755 /diretorio onde 3 (1+2) é o valor q ativa so SGID-BIT e STICK-BIT Quaisquer dúvidas estou a disposição. PS: o 755 foi por minha conta, vc deve obedecer a permissao que deseja no diretorio. Att Leandro Moreira. On Wed, 12 Nov 2008 15:31:13 -0200, Adauto Serpa [EMAIL PROTECTED] wrote: Boa tarde Pessoal, Estou com um problema com relação a permissões de arquivos. Meu caso é o seguinte: tenho no meu servidor um diretório compartilhando pelo samba chamado distribuidora com as seguintes permissões drwxrwx--- 9 distribuidora distribuidora 4,0K Nov 12 15:06 distribuidora Gostaria que cada novo diretório ou arquivo que fosse criado, forçasse o grupo a ser distribuidora e permitir a gravação para o grupo, pois meu usuário faz parte do grupo informatica e distribuidora logo gostaria de ter acesso a total a esse diretorio sem ter que ficar setando as permissões com o root. Não tenho a mínima idéia de como faço isso. Nem sei se essa é a melhor idéia de fazer isso. desde já agradeço, -- Adauto Serpa Tecnólogo em Informática Jabber: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] !DSPAM:1,491b1754223151168211527! -- Leandro Moreira Linux Networks e-mail: [EMAIL PROTECTED] Tel.: + 55(32) 9906-5713 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Herdando Permissões de Pastas e Arquivos
Boa tarde Pessoal, Estou com um problema com relação a permissões de arquivos. Meu caso é o seguinte: tenho no meu servidor um diretório compartilhando pelo samba chamado distribuidora com as seguintes permissões drwxrwx--- 9 distribuidora distribuidora 4,0K Nov 12 15:06 distribuidora Gostaria que cada novo diretório ou arquivo que fosse criado, forçasse o grupo a ser distribuidora e permitir a gravação para o grupo, pois meu usuário faz parte do grupo informatica e distribuidora logo gostaria de ter acesso a total a esse diretorio sem ter que ficar setando as permissões com o root. Não tenho a mínima idéia de como faço isso. Nem sei se essa é a melhor idéia de fazer isso. desde já agradeço, -- Adauto Serpa Tecnólogo em Informática Jabber: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Herdando Permissões de Pastas e Arquivos
Adauto, No seu caso oq ue vc precisa e do SGID-BIT , assim todos os arquivos e pastas criado no diretório terao o grupo do diretório corrente, caso queira aumnetar a segurança tb pode ativar o STICK-BIT, pois assim so o dono do arquivo ou pasta pode deleta-lo ## SGID-BIT chmod 2755 /diretorio onde 2 é o valor q ativa so SGID-BIT ## STICK-BIT chmod 1755 /diretorio onde 1 é o valor q ativa so SGID-BIT ## SITCK-BIT + SGID-BIT chmod 3755 /diretorio onde 3 (1+2) é o valor q ativa so SGID-BIT e STICK-BIT Quaisquer dúvidas estou a disposição. PS: o 755 foi por minha conta, vc deve obedecer a permissao que deseja no diretorio. Att Leandro Moreira. On Wed, 12 Nov 2008 15:31:13 -0200, Adauto Serpa [EMAIL PROTECTED] wrote: Boa tarde Pessoal, Estou com um problema com relação a permissões de arquivos. Meu caso é o seguinte: tenho no meu servidor um diretório compartilhando pelo samba chamado distribuidora com as seguintes permissões drwxrwx--- 9 distribuidora distribuidora 4,0K Nov 12 15:06 distribuidora Gostaria que cada novo diretório ou arquivo que fosse criado, forçasse o grupo a ser distribuidora e permitir a gravação para o grupo, pois meu usuário faz parte do grupo informatica e distribuidora logo gostaria de ter acesso a total a esse diretorio sem ter que ficar setando as permissões com o root. Não tenho a mínima idéia de como faço isso. Nem sei se essa é a melhor idéia de fazer isso. desde já agradeço, -- Adauto Serpa Tecnólogo em Informática Jabber: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] !DSPAM:1,491b1754223151168211527! -- Leandro Moreira Linux Networks e-mail: [EMAIL PROTECTED] Tel.: + 55(32) 9906-5713 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problemas com permissões
Olá a todos Eu estou com ese problema. Eu tentei reiniciar o syslogd depois de uma pequena alteração no arquivo de configuraçãoe por alguma razãoele não quer mais reiniciar. As mensagens de inicialização mostram que tem alguma coisa errada com dois arquivos: klogd.pid e syslogd.pid. Executando ls -l em /var/run eu recebo: ?- ? ? ? ? ? klogd.pid ?- ? ? ? ? ? syslogd.pid drwxr-xr-x 2 root root 4096 Jul 10 00:07 sshd (e pos aí vai) Eu não consigo escrever, remover ou fazer qualquer coisa com esses arquivos. Como vocÊs podem ver, se eu executar ls eles são listados, mas se executar vim /var/run, esses arquivos não estão lá. Alguém pode me dizer o que deve ser feito? -- __ Rodrigo de Castro Cosme Ciência da Computação - Universidade Federal do Espírito Santo Suporte mailing list - [EMAIL PROTECTED] MSN - [EMAIL PROTECTED]
Re: Problemas com permissões
Rodrigo Cosme escreveu: Olá a todos Eu estou com ese problema. Eu tentei reiniciar o syslogd depois de uma pequena alteração no arquivo de configuraçãoe por alguma razãoele não quer mais reiniciar. As mensagens de inicialização mostram que tem alguma coisa errada com dois arquivos: klogd.pid e syslogd.pid. Executando ls -l em /var/run eu recebo: ?- ? ? ? ? ? klogd.pid ?- ? ? ? ? ? syslogd.pid drwxr-xr-x 2 root root 4096 Jul 10 00:07 sshd (e pos aí vai) Eu não consigo escrever, remover ou fazer qualquer coisa com esses arquivos. Como vocÊs podem ver, se eu executar ls eles são listados, mas se executar vim /var/run, esses arquivos não estão lá. Alguém pode me dizer o que deve ser feito? -- __ Rodrigo de Castro Cosme Ciência da Computação - Universidade Federal do Espírito Santo Suporte mailing list - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] MSN - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Primeiro de tudo certifique-se de que o syslog não esteja rodando: # ps aux | grep syslogd # ps aux | grep klogd Os arquivos estão aparecendo sem permissão e sem dono? Tenha certeza de que o usuário root esteja em /etc/passwd, e que o syslog não esteja rodando, então depois de um: # chown root.root *logd.pid # rm *logd.pid Porque aconteceu isso? Podem ser varias coisas, duas delas o root *sumiu* do /etc/passwd ou o seu sistema de arquivo está corrompendo, aconselho a bootar a maquina em singleuser mode e passar um fsck geral. A[]'s -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problemas com permissões
Rodrigo Cosme escreveu: As mensagens de inicialização mostram que tem alguma coisa errada com dois arquivos: klogd.pid e syslogd.pid. Executando ls -l em /var/run eu recebo: ?- ? ? ? ? ? klogd.pid ?- ? ? ? ? ? syslogd.pid drwxr-xr-x 2 root root 4096 Jul 10 00:07 sshd (e pos aí vai) Sistem de arquivos corrompido. Espero que você tenha um backup atualizado. Att, Renato -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissões Linux X Samba
2008/7/6 Adriano escreveu: Ative o stick bit no diretorio pai para que seja respeitada as permissões do grupo. Assim quaisquer arquivos e diretórios novos criados dentro do diretório serão possuídos pelo usuários que os criaram, mas o grupo será sempre o mesmo do diretório-mãe. Assim, os demais usuários do grupo também terão acesso garantido aos novos arquivos e diretórios. 2008/7/6 Julio escreveu: Adriano, essa do stick bit é uma boa. Não sabia que esta também era a função dele. Achava que era apenas para não permitir que o usuário que não criou o arquivo pudesse apagar, essas coisas assim. E não é mesmo função do stick bit fazer com o grupo dos arquivos seja o mesmo do diretório mãe. Vamos a um teste simples? $ mkdir lixo $ ls -ld lixo drwxr-xr-x 2 bruno bruno 4096 2008-07-08 08:46 lixo $ sudo chown bruno:users lixo $ sudo chmod o+t lixo $ ls -ld lixo drwxr-xr-t 2 bruno users 4096 2008-07-08 08:46 lixo $ cd lixo $ touch teste $ ls -l total 0 -rw-r--r-- 1 bruno bruno 0 2008-07-08 08:47 teste $ -- Bruno Schneider http://www.dcc.ufla.br/~bruno/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Permissões Linux X Samba
Olá pessoal. Tenho uma dúvida, acredito ser coisa simples. Quando crio um compartilhamento no samba, posso setar o grupo que terá acesso aos arquivos do compartilhamento: valid users = +financeiro Adiciono um usuário para o grupo financeiro: useradd fulano -G joao -d /dev/null -s /bin/false Dessa forma, o usuário será cadastrado no grupo financeiro normalmente. Mas junto com isso, é criado um grupo (sem nenhum usuário setado) com o nome joao em /etc/group: joao:x:1021: E aqui vem o problema: Quando crio um compartilhamento, dou acesso total somente ao dono (quem criou, joao no caso) e ao grupo dele (financeiro)valid users = +financeiro... Mas quando o usuário joao cria um diretório em qualquer lugar, o diretório recebe o dono joao e o grupo joao com permissões - drwxrwxr-x, somente para o grupo joão e para o usuário joão (não o grupo autorizado pelo compartilhamento, que é o grupo financeiro) . Logo, outro usuário (que é do grupo financeiro, e não do grupo joao) não tem acesso, pois eu defini que somente os usuários do grupo poderão ter acesso, porém o novo diretório terá permissões de escrita somente para o próprio grupo joao (e não para outros usuários do grupo financeiro). drwxrwxr-x 2 joao joao 48 2008-06-25 15:40 teste O problema está na criação de arquivos e diretórios pelos usuários. Cada usuário pertencente ao grupo financeiro deverá criar seus diretórios mapeando os mesmos para o grupo financeiro, e não o grupo criado automaticamente com o nome do usuário. Alguém sabe como posso arrumar isso? Setei as opções do samba para forçar criar arquivos e diretórios escancarados, porém não é a melhor opção... force create mode = 0777 force directory mode = 0777 Alguma ajuda? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissões Linux X Samba
Julio
Ative o stick bit no diretorio pai para que seja respeitada as permissões do
grupo. Assim quaisquer arquivos e diretórios novos criados dentro do diretório
serão possuídos pelo usuários que os criaram, mas o grupo será sempre o mesmo
do diretório-mãe. Assim, os demais usuários do grupo também terão acesso
garantido aos novos arquivos e diretórios.
Ex: chmod 2770 /financeiro (diretorio pai)
no smb.conf
[financeiro]
browseable = yes
path = /financeiro
writable = yes
create mode = 2770
force security mode = 2770
directory mode = 2770
force create mode = 2770
force directory mode = 2770
force directory security mode = 2770
{]´s
--- Em dom, 6/7/08, Julio [EMAIL PROTECTED] escreveu:
De: Julio [EMAIL PROTECTED]
Assunto: Permissões Linux X Samba
Para: debian-user-portuguese@lists.debian.org
Data: Domingo, 6 de Julho de 2008, 3:57
Olá pessoal.
Tenho uma dúvida, acredito ser coisa simples.
Quando crio um compartilhamento no samba, posso setar o
grupo que terá
acesso aos arquivos do compartilhamento:
valid users = +financeiro
Adiciono um usuário para o grupo financeiro:
useradd fulano -G joao -d /dev/null -s /bin/false
Dessa forma, o usuário será cadastrado no grupo
financeiro
normalmente.
Mas junto com isso, é criado um grupo (sem nenhum usuário
setado) com
o nome joao em /etc/group:
joao:x:1021:
E aqui vem o problema: Quando crio um compartilhamento, dou
acesso
total somente ao dono (quem criou, joao no caso) e ao grupo
dele
(financeiro)valid users = +financeiro...
Mas quando o usuário joao cria um diretório em qualquer
lugar, o
diretório recebe o dono joao e o grupo
joao com permissões -
drwxrwxr-x, somente para o grupo joão e para o usuário
joão (não o
grupo autorizado pelo compartilhamento, que é o grupo
financeiro) .
Logo, outro usuário (que é do grupo financeiro, e não do
grupo joao)
não tem acesso, pois eu defini que somente os usuários do
grupo
poderão ter acesso, porém o novo diretório terá
permissões de escrita
somente para o próprio grupo joao (e não para outros
usuários do grupo
financeiro).
drwxrwxr-x 2 joao joao 48 2008-06-25 15:40 teste
O problema está na criação de arquivos e diretórios
pelos usuários.
Cada usuário pertencente ao grupo financeiro deverá criar
seus
diretórios mapeando os mesmos para o grupo financeiro, e
não o grupo
criado automaticamente com o nome do usuário.
Alguém sabe como posso arrumar isso?
Setei as opções do samba para forçar criar arquivos e
diretórios
escancarados, porém não é a melhor
opção...
force create mode = 0777
force directory mode = 0777
Alguma ajuda?
--
To UNSUBSCRIBE, email to
[EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]
Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua
cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissões Linux X Samba
Olá, Julio escreveu: Olá pessoal. Tenho uma dúvida, acredito ser coisa simples. Quando crio um compartilhamento no samba, posso setar o grupo que terá acesso aos arquivos do compartilhamento: valid users = +financeiro Adiciono um usuário para o grupo financeiro: useradd fulano -G joao -d /dev/null -s /bin/false Por quê não adicionar o usuário diretamente já no grupo financeiro ? Usando sua sintaxe acima, ficaria algo como : $ useradd fulano -G financeiro -d /dev/null -s /bin/false Dessa forma, o usuário será cadastrado no grupo financeiro normalmente. Mas junto com isso, é criado um grupo (sem nenhum usuário setado) com o nome joao em /etc/group: joao:x:1021: Sim, mas você poderia evitar esse problema criando o usuário já com seu grupo inicial (grupo primário) como sendo o grupo financeiro, o que faria com que quaisquer arquivos e diretórios criados pelo mesmo tivessem como grupo o grupo financeiro e não o grupo joao. Ainda usando sua sintaxe para o useradd, ficaria algo como : $ useradd fulano -g financeiro -d /dev/null -s /bin/false E aqui vem o problema: Quando crio um compartilhamento, dou acesso total somente ao dono (quem criou, joao no caso) e ao grupo dele (financeiro)valid users = +financeiro... Mas quando o usuário joao cria um diretório em qualquer lugar, o diretório recebe o dono joao e o grupo joao com permissões - drwxrwxr-x, somente para o grupo joão e para o usuário joão (não o grupo autorizado pelo compartilhamento, que é o grupo financeiro) . Uma coisa é autorizar qual o grupo tem acesso ao compartilhamento pelo Samba (via valid users) e outra é definir qual o grupo inicial/primário do usuário na criação do próprio usuário. A criação de arquivos e diretórios por padrão (independente de Samba, mesmo em GNU/Linux puro) sempre usa como grupo o grupo inicial/primário do usuário, o qual você especificou como joao em seu exemplo. Se você especificar como financeiro, seu problema é resolvido. Logo, outro usuário (que é do grupo financeiro, e não do grupo joao) não tem acesso, pois eu defini que somente os usuários do grupo poderão ter acesso, porém o novo diretório terá permissões de escrita somente para o próprio grupo joao (e não para outros usuários do grupo financeiro). drwxrwxr-x 2 joao joao 48 2008-06-25 15:40 teste Novamente, se você definir o grupo inicial/primário do usuário como financeiro, os arquivos/diretórios criados pelo mesmo terão como grupo o grupo financeiro e, dessa forma, outro usuários do grupo financeiro terão acesso aos mesmos conforme você deseja. O problema está na criação de arquivos e diretórios pelos usuários. Cada usuário pertencente ao grupo financeiro deverá criar seus diretórios mapeando os mesmos para o grupo financeiro, e não o grupo criado automaticamente com o nome do usuário. Alguém sabe como posso arrumar isso? Criando o usuário já com seu grupo inicial/primário como o grupo financeiro :-) É uma das opções, veja outras abaixo. Setei as opções do samba para forçar criar arquivos e diretórios escancarados, porém não é a melhor opção... force create mode = 0777 force directory mode = 0777 Alguma ajuda? Caso não queira ou não possa criar os usuários já com grupo inicial/primário como o grupo financeiro, você pode usar a diretiva force group dentro do compartilhamento no qual você quer que todos os arquivos e diretórios criados tenham como grupo o grupo financeiro. Por exemplo [financeiro] ... force group = financeiro ... Isso força os arquivos e diretórios criados dentro desse compartilhamento (somente via Samba) a sempre terem o grupo financeiro, mesmo o grupo inicial/primário dos usuários sendo outro grupo diferente do grupo financeiro. Opcionalmente, você pode usar o suporte a ACLs de sistema de arquivos (comandos setfacl no pacote Debian de nome acl) e definir uma ACL default para o diretório apontando pelo compartilhamento em questão indicando que o grupo financeiro sempre terá as permissões que você deseja para o grupo financeiro e todos os arquivos e diretórios criados sob o mesmo herdarão tais permissões. Exemplo : $ setfacl -d -m g:financeiro:rwx /diretorio/compartilhamento/financeiro Logicamente, lembrando que, para ter a possibilidade de utilizar ACLs de sistema de arquivos, a partição que contém o sistema de arquivos que irá receber as ACLs precisa estar montada com a opção de permissão de uso de ACLs definida (opção acl na montagem da partição em questão). Espero ter ajudado. Atenciosamente, -- André Luís Lopes [EMAIL PROTECTED],debian}.org http://www.andrelop.org/blog/ Public GPG KeyID : 9D1B82F6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissões Linux X Samba
Pessoal, obrigado pelas respostas. Entendi bastante coisa com a explicação de vocês. Adriano, essa do stick bit é uma boa. Não sabia que esta também era a função dele. Achava que era apenas para não permitir que o usuário que não criou o arquivo pudesse apagar, essas coisas assim. Mas estou tentando fazer o que o André sugeriu. Pelo que entendi André, estava usando a opção errada: Estava usando # useradd teste -G informatica -s /bin/false -d /dev/ null (com G maiúsculo) Aí tentei colocando o -g (minúsculo). Acredito que o -G serve para criar um grupo primário com o nome do usuário, e acrescentar o usuário no outro grupo especificado depois do -G. Porém, a dificuldade está na hora de criar o usuário. Aqui no meu sistema tenho 2 arquivos pra grupos (acredito serem só esses): /etc/group e /etc/group- Mas o problema é simples: Ao usar o comando useradd teste -g informatica -s /bin/false -d /dev/null ele acrescenta o usuário no arquivo /etc/passwd e /etc/shadow, porém não adiciona o mesmo nos arquivos group e group- que citei. Será que o sistema usa outro arquivo para fazer essa referência de grupo. Acabei de executar o comando: useradd abc -g informatica -s /bin/false -d /dev/null E verifiquei os dois arquivos group e group-: informatica:x:1003:jose,maria informatica:x:1003:jose,maria O que será que acontece? Esses dias apaguei grupos primários de alguns usuários (fazendo testes). Mas depois exclui os usuários. Será que o sistema se perde por eu ter editado o arquivo manualmente? Por quê não adicionar o usuário diretamente já no grupo financeiro ? Usando sua sintaxe acima, ficaria algo como : $ useradd fulano -G financeiro -d /dev/null -s /bin/false Dessa forma, o usuário será cadastrado no grupo financeiro normalmente. Mas junto com isso, é criado um grupo (sem nenhum usuário setado) com o nome joao em /etc/group: joao:x:1021: Sim, mas você poderia evitar esse problema criando o usuário já com seu grupo inicial (grupo primário) como sendo o grupo financeiro, o que faria com que quaisquer arquivos e diretórios criados pelo mesmo tivessem como grupo o grupo financeiro e não o grupo joao. Ainda usando sua sintaxe para o useradd, ficaria algo como : $ useradd fulano -g financeiro -d /dev/null -s /bin/false Foi mal, coloquei o parâmetro errado. Era para ser -G financeiro no lugar de -G joao. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Samba - Mapeamento de Permissões
Voce consegue baixar os grupos e usuario de ser PDC através do winbind... Procure ajuda no site oficial do samba que lá existe um passo a passo... Fernando Mariano. On Wed, 2008-01-23 at 02:18 -0200, Felipe Augusto van de Wiel (faw) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22-01-2008 16:39, Wendell Almeida wrote: Saudações. Tenho um servidor Samba com o seguinte compartilhamento: [16:23] [EMAIL PROTECTED] [init.d]$ l /samba/administrativo/ total 2 drwxrwx--- 12 root comercial 584 2008-01-21 12:41 comercial drwxrwx--- 14 root diretoria 464 2008-01-21 13:11 diretoria drwxrwx--- 8 root financeiro 368 2008-01-21 12:56 financeiro drwxrwx--- 9 root rh 592 2008-01-22 15:46 rh drwxrwx--- 9 root secretaria 472 2008-01-22 09:59 secretaria No servidor tem um usuário chamado wendell que pertence aos grupos acima. Quando monto esse compartilhamento em uma máquina Linux remota as permissões ficam da seguinte forma: [16:33] [EMAIL PROTECTED] [root]$ mount.smbfs //pitta/administrativo /mnt/tmp/ -o username=wendell [16:33] [EMAIL PROTECTED] [root]$ l /mnt/tmp/ total 0 drwxrwx--- 1 root 1009 0 Jan 21 12:41 comercial drwxrwx--- 1 root 1007 0 Jan 21 13:11 diretoria drwxrwx--- 1 root 1006 0 Jan 21 12:56 financeiro drwxrwx--- 1 root 1008 0 Jan 22 15:46 rh drwxrwx--- 1 root 1005 0 Jan 22 09:59 secretaria O id dos grupos acima são os mesmos do servidor samba, no entanto não tenho esses grupos localmente. Tenho somente o usuário wendell criado. E não consigo mudar as permissões: [16:38] [EMAIL PROTECTED] [root]$ chown wendell: /mnt/tmp/* chown: changing ownership of `/mnt/tmp/comercial': Operation not permitted chown: changing ownership of `/mnt/tmp/diretoria': Operation not permitted chown: changing ownership of `/mnt/tmp/financeiro': Operation not permitted chown: changing ownership of `/mnt/tmp/rh': Operation not permitted chown: changing ownership of `/mnt/tmp/secretaria': Operation not permitted Tem alguma forma de mudar essas permissões para que o user wendell possa acessar os arquivos? Crie os grupos ou use algo como NIS ou LDAP. Ou, use ACLs para dar permisão para o wendell e não para os grupos. Ou, use NFS para montar sistemas de arquivos remotos que estão em máquinas unix-like. Abraço, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlsE+CjAO0JDlykYRApqdAJ4ridKdq5/XO4feLN0gMzUlgbqsygCgtwEW Y5ATjGbY8CwFpcPEFPQxztM= =VSz7 -END PGP SIGNATURE-
Samba - Mapeamento de Permissões
Saudações. Tenho um servidor Samba com o seguinte compartilhamento: [16:23] [EMAIL PROTECTED] [init.d]$ l /samba/administrativo/ total 2 drwxrwx--- 12 root comercial 584 2008-01-21 12:41 comercial drwxrwx--- 14 root diretoria 464 2008-01-21 13:11 diretoria drwxrwx--- 8 root financeiro 368 2008-01-21 12:56 financeiro drwxrwx--- 9 root rh 592 2008-01-22 15:46 rh drwxrwx--- 9 root secretaria 472 2008-01-22 09:59 secretaria No servidor tem um usuário chamado wendell que pertence aos grupos acima. Quando monto esse compartilhamento em uma máquina Linux remota as permissões ficam da seguinte forma: [16:33] [EMAIL PROTECTED] [root]$ mount.smbfs //pitta/administrativo /mnt/tmp/ -o username=wendell [16:33] [EMAIL PROTECTED] [root]$ l /mnt/tmp/ total 0 drwxrwx--- 1 root 1009 0 Jan 21 12:41 comercial drwxrwx--- 1 root 1007 0 Jan 21 13:11 diretoria drwxrwx--- 1 root 1006 0 Jan 21 12:56 financeiro drwxrwx--- 1 root 1008 0 Jan 22 15:46 rh drwxrwx--- 1 root 1005 0 Jan 22 09:59 secretaria O id dos grupos acima são os mesmos do servidor samba, no entanto não tenho esses grupos localmente. Tenho somente o usuário wendell criado. E não consigo mudar as permissões: [16:38] [EMAIL PROTECTED] [root]$ chown wendell: /mnt/tmp/* chown: changing ownership of `/mnt/tmp/comercial': Operation not permitted chown: changing ownership of `/mnt/tmp/diretoria': Operation not permitted chown: changing ownership of `/mnt/tmp/financeiro': Operation not permitted chown: changing ownership of `/mnt/tmp/rh': Operation not permitted chown: changing ownership of `/mnt/tmp/secretaria': Operation not permitted Tem alguma forma de mudar essas permissões para que o user wendell possa acessar os arquivos? Obrigado. Wendell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Samba - Mapeamento de Permissões
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22-01-2008 16:39, Wendell Almeida wrote: Saudações. Tenho um servidor Samba com o seguinte compartilhamento: [16:23] [EMAIL PROTECTED] [init.d]$ l /samba/administrativo/ total 2 drwxrwx--- 12 root comercial 584 2008-01-21 12:41 comercial drwxrwx--- 14 root diretoria 464 2008-01-21 13:11 diretoria drwxrwx--- 8 root financeiro 368 2008-01-21 12:56 financeiro drwxrwx--- 9 root rh 592 2008-01-22 15:46 rh drwxrwx--- 9 root secretaria 472 2008-01-22 09:59 secretaria No servidor tem um usuário chamado wendell que pertence aos grupos acima. Quando monto esse compartilhamento em uma máquina Linux remota as permissões ficam da seguinte forma: [16:33] [EMAIL PROTECTED] [root]$ mount.smbfs //pitta/administrativo /mnt/tmp/ -o username=wendell [16:33] [EMAIL PROTECTED] [root]$ l /mnt/tmp/ total 0 drwxrwx--- 1 root 1009 0 Jan 21 12:41 comercial drwxrwx--- 1 root 1007 0 Jan 21 13:11 diretoria drwxrwx--- 1 root 1006 0 Jan 21 12:56 financeiro drwxrwx--- 1 root 1008 0 Jan 22 15:46 rh drwxrwx--- 1 root 1005 0 Jan 22 09:59 secretaria O id dos grupos acima são os mesmos do servidor samba, no entanto não tenho esses grupos localmente. Tenho somente o usuário wendell criado. E não consigo mudar as permissões: [16:38] [EMAIL PROTECTED] [root]$ chown wendell: /mnt/tmp/* chown: changing ownership of `/mnt/tmp/comercial': Operation not permitted chown: changing ownership of `/mnt/tmp/diretoria': Operation not permitted chown: changing ownership of `/mnt/tmp/financeiro': Operation not permitted chown: changing ownership of `/mnt/tmp/rh': Operation not permitted chown: changing ownership of `/mnt/tmp/secretaria': Operation not permitted Tem alguma forma de mudar essas permissões para que o user wendell possa acessar os arquivos? Crie os grupos ou use algo como NIS ou LDAP. Ou, use ACLs para dar permisão para o wendell e não para os grupos. Ou, use NFS para montar sistemas de arquivos remotos que estão em máquinas unix-like. Abraço, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlsE+CjAO0JDlykYRApqdAJ4ridKdq5/XO4feLN0gMzUlgbqsygCgtwEW Y5ATjGbY8CwFpcPEFPQxztM= =VSz7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
rsync mantendo as permissões dos arquivos sincronizados
Olá pessoal, Estou acertando uma rotina para sincronizar os scripts de logon do samba entre um PDC e seu BDC. Estou usando a ferramente rsync com autenticação por ssh para fazer a transferência. Meu problema é que cada grupo de usuário tem acesso restrito ao seu respectivo script, que fica bloqueado para os demais usuários. Criei um usuário no sistema para fazer esta replicação, mas como suas permissões são de usuário comum não funcionou obviamente. Nos artigos que consultei o pessoal disse que não é recomedavel criar o acesso do ssh sem senha para o usuário root (o que resolveria meu problema neste caso). Alguma sugestão de como resolver este problema Não vou alterar constantemente estes arquivos, mas qdo alterar preciso que fiquem atualizados nas duas pontas, uma vez que se o PDC cair, o BDC assume o lugar dele. Desde já obrigado. Abraço Pedro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rsync mantendo as permissões dos arquivos sincronizados
Em Sex, 2007-12-28 às 11:10 -0200, Pedro Debian escreveu: Olá pessoal, Olá Estou acertando uma rotina para sincronizar os scripts de logon do samba entre um PDC e seu BDC. Estou usando a ferramente rsync com autenticação por ssh para fazer a transferência. Meu problema é que cada grupo de usuário tem acesso restrito ao seu respectivo script, que fica bloqueado para os demais usuários. Criei um usuário no sistema para fazer esta replicação, mas como suas permissões são de usuário comum não funcionou obviamente. Nos artigos que consultei o pessoal disse que não é recomedavel criar o acesso do ssh sem senha para o usuário root (o que resolveria meu problema neste caso). ok pelo que eu notei vc tem que copiar dados de um lado para outro correto? vc pode fazer isto usando: a) o rsync com ou sem ssh b) usando o DRBD c) montando o diretório de logins scripts via NFS e montando e copiando na outra maquina d) montando o diretório de logins scripts via samba e montando e copiando na outra maquina e) usando o rcp ( argh ) bem das 5 opções acima creio que a mais facil seria o caminho que vc está fazendo se vc procura segurança, creio que as opçôes b) e c) ou d) serviriam espero ter ajudado []s Alguma sugestão de como resolver este problema Não vou alterar constantemente estes arquivos, mas qdo alterar preciso que fiquem atualizados nas duas pontas, uma vez que se o PDC cair, o BDC assume o lugar dele. Desde já obrigado. Abraço Pedro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rsync mantendo as permissões dos arquivos sincronizados
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28-12-2007 11:10, Pedro Debian wrote: Olá pessoal, Estou acertando uma rotina para sincronizar os scripts de logon do samba entre um PDC e seu BDC. Estou usando a ferramente rsync com autenticação por ssh para fazer a transferência. Meu problema é que cada grupo de usuário tem acesso restrito ao seu respectivo script, que fica bloqueado para os demais usuários. Criei um usuário no sistema para fazer esta replicação, mas como suas permissões são de usuário comum não funcionou obviamente. Nos artigos que consultei o pessoal disse que não é recomedavel criar o acesso do ssh sem senha para o usuário root (o que resolveria meu problema neste caso). Alguma sugestão de como resolver este problema Não vou alterar constantemente estes arquivos, mas qdo alterar preciso que fiquem atualizados nas duas pontas, uma vez que se o PDC cair, o BDC assume o lugar dele. Desde já obrigado. Você pode usar algo como DRDB ou um terceiro ponto como NFS. Mas você pode usar POSIX ACL para dar permissão para que o usuário que faz a sincronia possa pelo menos ler os arquivos numa ponta e gravá-los na outra. Abraço, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHdSKuCjAO0JDlykYRAtc9AKDPI7oVPRG6modxHbw+JZsnXugN8QCfZlSz BhR1LLXaiAJt+jKStOrdZ6M= =Bm7F -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissões malucas com Pen-drive
Olha, normalmente funciona por aqui. Mas se para voce nao esta funcionando entao faz assim : execute : ls -l /dev/disk/by-uuid/ identifique o UUID do seu pendrive que deve aparecer como sdMN seguido dum codigo estrambolico que chamamos de UUID, depois voce edita o arquivo /etc/fstab e acrescenta seu pendrive com a linha : UUID=6b8bd4e2-cee9-4eef-a0d4-9ee589cd584b /media/pendrive autonoauto,users,user,umask=000 0 0 Substitua o UUID acima por aquele que voce encontrou no ls -l /dev/disk/by-uuid/. Também crie a pasta onde será montado o dispositivo : mkdir -p /media/pendrive e dê permissão global a pasta : chmod 0777 /media/pendrive Com isso não importará onde voce plugará o pendrive ele sempre montará no local indicado e com permissões publicas. Quando espetar o pendrive provavelmente o gnome montará no local indicado, se ele nao automontar, pelo menos vai aparecer na relacao de discos do painel lateral do nautilus e com um clique com o botao direito voce poderá monta-lo. Mas o melhor mesmo era voce descobrir porque o seu GNOME precisa dessa trabalheira toda se por default nao precisamos nada disso. []'s Em 22/12/07, Waltair Santos[EMAIL PROTECTED] escreveu: Sávio! boa tarde! Você conseguiu resolver este problema (montagem de pen drive com permissão de escrita para todos os users que logarem no sistema)? Será que no kde funciona assim também? Abraços p.s.: já tive este problema, porém não consegui resolver até agora. - Mensagem original De: Sávio Ramos [EMAIL PROTECTED] Para: debian-user-portuguese@lists.debian.org Enviadas: Quinta-feira, 13 de Dezembro de 2007 13:24:56 Assunto: Re: Permissões malucas com Pen-drive Em Thu, 13 Dec 2007 11:17:17 -0200 Fabiano Manoel de Andrade [EMAIL PROTECTED] escreveu: Isso acontece porque o primeiro usuário criado é adicionado ao grupo plugdev e os outros não. O sistema está fazendo montagem automática, não? Veja se resolve adicionando os usuário a este grupo. Os usuários já estão no grupo plugdev... Sim, o Gnome está montando automaticamente o chupa-cabra. -- Sávio M Ramos Arquiteto, Rio, RJ Só uso Linux desde 2000 www.debian.org Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
Re: Permissões malucas com Pen-drive
Em Sat, 22 Dec 2007 17:51:36 -0200 Still [EMAIL PROTECTED] escreveu: /dev/sda1 /pen_drive vfatnoauto,user,umask=000 0 0 ^^^ Creio que o problema está aí, não uso vfat nos dispositivos. Estão formatados com XFS como os meus discos... -- Sávio M Ramos Arquiteto, Rio, RJ Só uso Linux desde 2000 www.debian.org
Re: Permissões malucas com Pen-drive
Em Sun, 23 Dec 2007 07:37:03 -0200 hamacker [EMAIL PROTECTED] escreveu: Mas o melhor mesmo era voce descobrir porque o seu GNOME precisa dessa trabalheira toda se por default nao precisamos nada disso. 1) Vou tentar o que disse e retorno; 2) Suspeito que tudo isto acontece por causa do XFS. O bichinho está formatado com xfs assim como meus discos rígidos... -- Sávio M Ramos Arquiteto, Rio, RJ Só uso Linux desde 2000 www.debian.org
Res: Permissões malucas com Pen-drive
Sávio! boa tarde! Você conseguiu resolver este problema (montagem de pen drive com permissão de escrita para todos os users que logarem no sistema)? Será que no kde funciona assim também? Abraços p.s.: já tive este problema, porém não consegui resolver até agora. - Mensagem original De: Sávio Ramos [EMAIL PROTECTED] Para: debian-user-portuguese@lists.debian.org Enviadas: Quinta-feira, 13 de Dezembro de 2007 13:24:56 Assunto: Re: Permissões malucas com Pen-drive Em Thu, 13 Dec 2007 11:17:17 -0200 Fabiano Manoel de Andrade [EMAIL PROTECTED] escreveu: Isso acontece porque o primeiro usuário criado é adicionado ao grupo plugdev e os outros não. O sistema está fazendo montagem automática, não? Veja se resolve adicionando os usuário a este grupo. Os usuários já estão no grupo plugdev... Sim, o Gnome está montando automaticamente o chupa-cabra. -- Sávio M Ramos Arquiteto, Rio, RJ Só uso Linux desde 2000 www.debian.org Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/
Re: Permissões malucas com Pen-drive
Em Sat, 22 Dec 2007 09:02:01 -0800 (PST) Waltair Santos [EMAIL PROTECTED] escreveu: Você conseguiu resolver este problema (montagem de pen drive com permissão de escrita para todos os users que logarem no sistema)? Não consegui, aliás só piorou... Descobri que alguns diretórios todos possuem permissão e outros permissão nenhuma. Sem lógica... Será que no kde funciona assim também? Não tenho a menor idéia. Usei o Kde uma semana em sete anos. Não por motivos da razão, falta de simpatia apenas. -- Sávio M Ramos Arquiteto, Rio, RJ Só uso Linux desde 2000 www.debian.org
Re: Permissões de usuário,
On Dec 20, 2007 6:16 PM, Rui Manuel Martins wrote: O debian não me deixa escrevr no meu disco externo, diz que o usuário não tem permissões para tal... como posso alterar as permissões de modo a que este possa escrever no disco externo? Se for um sistema ext2/ext3 e você quiser dar permissão para um único usuário, eu sugiro usar o chown para alterar o dono dos arquivos e diretórios. Agora se for outra coisa, vai ser preciso dar mais detalhes sobre o que você tem e quer fazer... -- Bruno Schneider http://www.dcc.ufla.br/~bruno/
