Re: [FUG-BR] OT Samba 4.4 dump core no FreeBSD 10.3

[Enio Marconcini]

2016-06-08 23:14 GMT-03:00 Paulo Olivier Cavalcanti :

> On 08/06/2016 15:54, Enio Marconcini wrote:
>
>> [...]
>>
>> ​Paulo boa tarde.
>> Boa tarde para os demais.
>>
>> Hoje tivemos os mesmos problemas de indisponibilidade ao acessar
>> determinados arquivos.
>> Além de acontecer ao abrir um arquivo, também durante a tentativa de
>> copiar
>> uma pasta, que travava e o Windows nem sequer chegava a começar a cópia,
>> apenas aparecia a barra de progresso congelada.
>>
>> Aumentei o nível de debug do Samba e fui ver os registros do arquivo de
>> log
>> do meu usuário enquanto tentava realizar a cópia da referida pasta. Dentre
>> os diversos avisos que tinham lá, encontrei alguma linha relacionada a ao
>> nome kilométrico do caminho para o arquivo bem como do próprio arquivo.
>>
>> Somando a isso, a opção "store dos atributes" ligada, junto com a opção
>> "acls" no fstab, alguns arquivos, que estavam com acls atribuídas, porém
>> tais acls foram criadas pelo próprio Windows (precisei usar acls em
>> algumas
>> pastas e permitir que um usuário controlasse pelo Windows as permissões de
>> uns arquivos).
>>
>> Percebi que a referida pasta que não estava sendo copiada possuía estava
>> numa sequencia grande de pastas dentro de outra pasta, com nomes longos, e
>> com alguns arquivos com nomes mais longos ainda. Resolvi encurtá-los para
>> testar. Aparentemente este não era o problema, visto que continuei tendo
>> problemas mesmo depois dos nomes mais curtos. (Obs: para encurtar os nomes
>> eu tive que renomear pelo shell, no Windows travava).
>>
>> O segundo passo foi remover as acls destes arquivos. Eram poucos e eu não
>> faço ideia de como que o Windows criou estes arquivos e atribuiu acls a
>> eles. Não foram atribuídas pelo setfacl (O samba armazenou as acls do
>> Windows visto que tinha essa permissão com store dos atributes, imagino
>> eu).
>>
>> Após remover as acls, foi instantâneo, eu consegui copiar as pastas.
>> Por fim eu rodei o comando: *find /pasta -acl -exec setfacl -bn {} \;*
>> para
>> remover de qualquer outro arquivo que por ventura estava com acl, e
>> desativei o store dos atributes do Samba, e pelo menos até o momento não
>> tive problemas, nem os usuários.
>>
>> ​Agora me falta debugar o motivo do problema que tive ontem com a pasta
>> compartilhada onde ficava os arquivos executáveis do ERP, no Samba 4.4,
>> acredito que não tenha relação com nomes longos nem acls, visto que neste
>> caso, os nomes são curtos, e sem nenhuma acl ajustada. ​
>>
>> Vou também testar o Samba 4.2 que vc recomendou. E relato aqui o
>> resultado.
>>
>>
>>
> Excelente feedback, Enio. Curiosamente, ontem eu analisei o seu smb4.conf
> e hoje eu iria lhe perguntar justamente do motivo dessa opção store dos
> attributes, já que ela é obsoleta.
>
> O Windows de vez em quando bagunça todas as acls que ele mesmo criou, é
> incompreensível.
>
> Que bom que tudo se resolveu.
>
>
> --
> http://about.me/paulocavalcanti
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



Bom dia.

Na verdade o store dos atributes não é o causador da criação das acls,
mesmo com ele desativado, continua aparecendo arquivos com acls setadas,
descobri que quando um arquivo de um usuário é alterado por outro, no Word
2013. Isso não estava acontecendo antes quando estes usuários utilizavam o
Office 2007 eheheheh.

Não entendo o motivo do erro durante a cópia de pastas, mas estava ligado a
pastas que possuíam arquivos com acls setadas.

Esse era o arquivo original, pertencendo ao usuário original​
-rw-rw   1 petter  sti11K  9 Jun 11:03 teste.docx​

Agora veja como ficou o arquivo, após ser aberto pelo meu usuário e
alterado e salvo por mim:
-rw-rwx---+  1 eniosti11K  9 Jun 11:11 teste.docx*

Como ficou as acls:
# file: teste.docx
# owner: enio
# group: sti
user::rw-
user:petter:rw-
group::rw-
mask::rwx
other::---

Observamos que, após o arquivo ser alterado pelo Word 2013, e ser salvo por
outro usuário, é atribuído as acls ao arquivo, e ficou dessa forma.
Eu só não entendi o motivo disso causar o problema na hora da cópia. Ou
isto está mascarando o problema, vai saber...

abraço



-- 
*[]'*
*Enio Rodrigo Marconcini*

*"Unix is user-friendly. It's just very selective about who its friends
are."*
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] OT Samba 4.4 dump core no FreeBSD 10.3

[Paulo Olivier Cavalcanti]

On 08/06/2016 15:54, Enio Marconcini wrote:

[...]

​Paulo boa tarde.
Boa tarde para os demais.

Hoje tivemos os mesmos problemas de indisponibilidade ao acessar
determinados arquivos.
Além de acontecer ao abrir um arquivo, também durante a tentativa de copiar
uma pasta, que travava e o Windows nem sequer chegava a começar a cópia,
apenas aparecia a barra de progresso congelada.

Aumentei o nível de debug do Samba e fui ver os registros do arquivo de log
do meu usuário enquanto tentava realizar a cópia da referida pasta. Dentre
os diversos avisos que tinham lá, encontrei alguma linha relacionada a ao
nome kilométrico do caminho para o arquivo bem como do próprio arquivo.

Somando a isso, a opção "store dos atributes" ligada, junto com a opção
"acls" no fstab, alguns arquivos, que estavam com acls atribuídas, porém
tais acls foram criadas pelo próprio Windows (precisei usar acls em algumas
pastas e permitir que um usuário controlasse pelo Windows as permissões de
uns arquivos).

Percebi que a referida pasta que não estava sendo copiada possuía estava
numa sequencia grande de pastas dentro de outra pasta, com nomes longos, e
com alguns arquivos com nomes mais longos ainda. Resolvi encurtá-los para
testar. Aparentemente este não era o problema, visto que continuei tendo
problemas mesmo depois dos nomes mais curtos. (Obs: para encurtar os nomes
eu tive que renomear pelo shell, no Windows travava).

O segundo passo foi remover as acls destes arquivos. Eram poucos e eu não
faço ideia de como que o Windows criou estes arquivos e atribuiu acls a
eles. Não foram atribuídas pelo setfacl (O samba armazenou as acls do
Windows visto que tinha essa permissão com store dos atributes, imagino eu).

Após remover as acls, foi instantâneo, eu consegui copiar as pastas.
Por fim eu rodei o comando: *find /pasta -acl -exec setfacl -bn {} \;* para
remover de qualquer outro arquivo que por ventura estava com acl, e
desativei o store dos atributes do Samba, e pelo menos até o momento não
tive problemas, nem os usuários.

​Agora me falta debugar o motivo do problema que tive ontem com a pasta
compartilhada onde ficava os arquivos executáveis do ERP, no Samba 4.4,
acredito que não tenha relação com nomes longos nem acls, visto que neste
caso, os nomes são curtos, e sem nenhuma acl ajustada. ​

Vou também testar o Samba 4.2 que vc recomendou. E relato aqui o resultado.




Excelente feedback, Enio. Curiosamente, ontem eu analisei o seu 
smb4.conf e hoje eu iria lhe perguntar justamente do motivo dessa opção 
store dos attributes, já que ela é obsoleta.


O Windows de vez em quando bagunça todas as acls que ele mesmo criou, é 
incompreensível.


Que bom que tudo se resolveu.

--
http://about.me/paulocavalcanti

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] OT Samba 4.4 dump core no FreeBSD 10.3

[Enio Marconcini]

2016-06-07 21:08 GMT-03:00 Paulo Olivier Cavalcanti :

> On 07/06/2016 20:54, Enio Marconcini wrote:
>
>> [...]
>>
>> Usamos a versão 4.2.11 sem problemas. Não instalamos a 4.4 porque vimos
>> que existem alguns problemas com estações windows 10.
>>
>> Você já experimentou colocar essas opções na sessão [global]:
>>
>> server signing = mandatory , ou
>> server signing = auto , e
>> ntlm auth = no
>>
>> Li em algum lugar que a série 4.4 fica mais estável com elas.
>>
>> Continue dando feedback sobre este caso, irá ajudar muita gente.
>>
>> --
>> http://about.me/paulocavalcanti
>>
>> -
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>>
>>
>> ​Paulo boa noite.
>> Hoje tive que manter o Samba 3.6 que não acontece o problema com os
>> arquivos executáveis que são abertos via rede, não acontecendo assim o
>> problema do core dump. Hoje ainda não tive o outro problema de
>> indisponibilidade ao abrir os outros arquivos via rede (do word
>> principalmente).
>> Irei analisar agora as diretivas usadas no Samba, para tentar descobrir se
>> é alguma em especial que causa o problema, pois talvez um mal ajuste pode
>> dar problema.
>>
>> Mesmo assim, irei testar a versão 4.2 recomendada por você, por questões
>> de
>> testes.
>>
>> Me diz, vc usa o samba aí em standalone mesmo, em modo ADS ou PDC.
>>
>> abraço​
>>
>>
>>
> O chato é ter que usar uma versão já descontinuada como a 3.6. Tomara que
> resolva logo. Vou pesquisar uma solução junto com você.
>
> Uso o Samba4 em modo PDC, gerenciando cerca de 35 usuários sem o menor
> problema.
>
> O FreeBSD é 9.3-RELEASE.
>
>
> --
> http://about.me/paulocavalcanti
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>




​Paulo boa tarde.
Boa tarde para os demais.

Hoje tivemos os mesmos problemas de indisponibilidade ao acessar
determinados arquivos.
Além de acontecer ao abrir um arquivo, também durante a tentativa de copiar
uma pasta, que travava e o Windows nem sequer chegava a começar a cópia,
apenas aparecia a barra de progresso congelada.

Aumentei o nível de debug do Samba e fui ver os registros do arquivo de log
do meu usuário enquanto tentava realizar a cópia da referida pasta. Dentre
os diversos avisos que tinham lá, encontrei alguma linha relacionada a ao
nome kilométrico do caminho para o arquivo bem como do próprio arquivo.

Somando a isso, a opção "store dos atributes" ligada, junto com a opção
"acls" no fstab, alguns arquivos, que estavam com acls atribuídas, porém
tais acls foram criadas pelo próprio Windows (precisei usar acls em algumas
pastas e permitir que um usuário controlasse pelo Windows as permissões de
uns arquivos).

Percebi que a referida pasta que não estava sendo copiada possuía estava
numa sequencia grande de pastas dentro de outra pasta, com nomes longos, e
com alguns arquivos com nomes mais longos ainda. Resolvi encurtá-los para
testar. Aparentemente este não era o problema, visto que continuei tendo
problemas mesmo depois dos nomes mais curtos. (Obs: para encurtar os nomes
eu tive que renomear pelo shell, no Windows travava).

O segundo passo foi remover as acls destes arquivos. Eram poucos e eu não
faço ideia de como que o Windows criou estes arquivos e atribuiu acls a
eles. Não foram atribuídas pelo setfacl (O samba armazenou as acls do
Windows visto que tinha essa permissão com store dos atributes, imagino eu).

Após remover as acls, foi instantâneo, eu consegui copiar as pastas.
Por fim eu rodei o comando: *find /pasta -acl -exec setfacl -bn {} \;* para
remover de qualquer outro arquivo que por ventura estava com acl, e
desativei o store dos atributes do Samba, e pelo menos até o momento não
tive problemas, nem os usuários.

​Agora me falta debugar o motivo do problema que tive ontem com a pasta
compartilhada onde ficava os arquivos executáveis do ERP, no Samba 4.4,
acredito que não tenha relação com nomes longos nem acls, visto que neste
caso, os nomes são curtos, e sem nenhuma acl ajustada. ​

Vou também testar o Samba 4.2 que vc recomendou. E relato aqui o resultado.


-- 
*[]'*
*Enio Rodrigo Marconcini*

*"Unix is user-friendly. It's just very selective about who its friends
are."*
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] OT Samba 4.4 dump core no FreeBSD 10.3

[Paulo Olivier Cavalcanti]

On 07/06/2016 20:54, Enio Marconcini wrote:

[...]
Usamos a versão 4.2.11 sem problemas. Não instalamos a 4.4 porque vimos
que existem alguns problemas com estações windows 10.

Você já experimentou colocar essas opções na sessão [global]:

server signing = mandatory , ou
server signing = auto , e
ntlm auth = no

Li em algum lugar que a série 4.4 fica mais estável com elas.

Continue dando feedback sobre este caso, irá ajudar muita gente.

--
http://about.me/paulocavalcanti

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd



​Paulo boa noite.
Hoje tive que manter o Samba 3.6 que não acontece o problema com os
arquivos executáveis que são abertos via rede, não acontecendo assim o
problema do core dump. Hoje ainda não tive o outro problema de
indisponibilidade ao abrir os outros arquivos via rede (do word
principalmente).
Irei analisar agora as diretivas usadas no Samba, para tentar descobrir se
é alguma em especial que causa o problema, pois talvez um mal ajuste pode
dar problema.

Mesmo assim, irei testar a versão 4.2 recomendada por você, por questões de
testes.

Me diz, vc usa o samba aí em standalone mesmo, em modo ADS ou PDC.

abraço​




O chato é ter que usar uma versão já descontinuada como a 3.6. Tomara 
que resolva logo. Vou pesquisar uma solução junto com você.


Uso o Samba4 em modo PDC, gerenciando cerca de 35 usuários sem o menor 
problema.


O FreeBSD é 9.3-RELEASE.

--
http://about.me/paulocavalcanti

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] OT Samba 4.4 dump core no FreeBSD 10.3

[Enio Marconcini]

2016-06-07 20:26 GMT-03:00 Paulo Olivier Cavalcanti :

> On 07/06/2016 09:58, Enio Marconcini wrote:
>
>> [...]O problema no Samba 4.4 é uma pasta compartilhada onde fica os
>> executáveis
>> do sistema ERP da empresa, sendo que os usuários acessam através do
>> caminho
>> de rede no atalho \\server\erp\compras\compras.exe por exemplo.
>> Quando o atalho é aberto, ou mesmo quando é executado dentro da pasta
>> compartilhada, acontece erro de violação de acesso.
>> Testei as permissões da pasta, coloquei 777 para diretório, e 444 para
>> arquivos, sem sucesso.
>>
>> Mas no Samba 3.6 essa mesma pasta funciona sem problema algum.
>>
>> OBS:
>> Tenho dois servidores trabalhando, estes mesmos problemas aconteceram nos
>> dois, FreeBSD 10.1 e no 10.3.
>> Tentei instalar o Samba via ports ou pkg.
>> Outra observação: a linha de erro no log (*unable to change to %N.core
>> e **refusing
>> to dump core) *quando eu procuro no google, os resultados aparece diversos
>> sites sobre FreeBSD. Será que este problema especificamente com o FreeBSD?
>>
>> Segue o .conf do Samba 4.4: *http://pastebin.com/raw/R0DeELXc
>> *
>>
>> Os erros que aparece no log do Samba 4.4 são estes:
>> Completo: *http://pastebin.com/raw/Xsyb9Prh
>> *
>>
>>
> Usamos a versão 4.2.11 sem problemas. Não instalamos a 4.4 porque vimos
> que existem alguns problemas com estações windows 10.
>
> Você já experimentou colocar essas opções na sessão [global]:
>
> server signing = mandatory , ou
> server signing = auto , e
> ntlm auth = no
>
> Li em algum lugar que a série 4.4 fica mais estável com elas.
>
> Continue dando feedback sobre este caso, irá ajudar muita gente.
>
> --
> http://about.me/paulocavalcanti
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



​Paulo boa noite.
Hoje tive que manter o Samba 3.6 que não acontece o problema com os
arquivos executáveis que são abertos via rede, não acontecendo assim o
problema do core dump. Hoje ainda não tive o outro problema de
indisponibilidade ao abrir os outros arquivos via rede (do word
principalmente).
Irei analisar agora as diretivas usadas no Samba, para tentar descobrir se
é alguma em especial que causa o problema, pois talvez um mal ajuste pode
dar problema.

Mesmo assim, irei testar a versão 4.2 recomendada por você, por questões de
testes.

Me diz, vc usa o samba aí em standalone mesmo, em modo ADS ou PDC.

abraço​


-- 
*[]'*
*Enio Rodrigo Marconcini*

*"Unix is user-friendly. It's just very selective about who its friends
are."*
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] OT Samba 4.4 dump core no FreeBSD 10.3

[Paulo Olivier Cavalcanti]

On 07/06/2016 09:58, Enio Marconcini wrote:

[...]O problema no Samba 4.4 é uma pasta compartilhada onde fica os executáveis
do sistema ERP da empresa, sendo que os usuários acessam através do caminho
de rede no atalho \\server\erp\compras\compras.exe por exemplo.
Quando o atalho é aberto, ou mesmo quando é executado dentro da pasta
compartilhada, acontece erro de violação de acesso.
Testei as permissões da pasta, coloquei 777 para diretório, e 444 para
arquivos, sem sucesso.

Mas no Samba 3.6 essa mesma pasta funciona sem problema algum.

OBS:
Tenho dois servidores trabalhando, estes mesmos problemas aconteceram nos
dois, FreeBSD 10.1 e no 10.3.
Tentei instalar o Samba via ports ou pkg.
Outra observação: a linha de erro no log (*unable to change to %N.core
e **refusing
to dump core) *quando eu procuro no google, os resultados aparece diversos
sites sobre FreeBSD. Será que este problema especificamente com o FreeBSD?

Segue o .conf do Samba 4.4: *http://pastebin.com/raw/R0DeELXc
*

Os erros que aparece no log do Samba 4.4 são estes:
Completo: *http://pastebin.com/raw/Xsyb9Prh
*



Usamos a versão 4.2.11 sem problemas. Não instalamos a 4.4 porque vimos 
que existem alguns problemas com estações windows 10.


Você já experimentou colocar essas opções na sessão [global]:

server signing = mandatory , ou
server signing = auto , e
ntlm auth = no

Li em algum lugar que a série 4.4 fica mais estável com elas.

Continue dando feedback sobre este caso, irá ajudar muita gente.

--
http://about.me/paulocavalcanti

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] OT Samba 4.4 dump core no FreeBSD 10.3

[Enio Marconcini]

Bom dia senhores.
Estou enfrentando um problema com o Samba 3.6 e com o Samba 4.4

Estou migrando o Samba 3.6/FreeBSD 10.1 para outro servidor rodando Samba
4.4/FreeBSD 10.3

O motivo da migração é que no Samba 3.6 está causando alguma
indisponibilidade em certos momentos, impedindo que usuários abram arquivos
pela rede e nem deixa copiar os arquivos.
E também que, quando eu instalo o Samba via ports relata problema de
vulnerabilidade, e pelo PKG relata que o pacote do samba 3.6 será
descontinuado.

No Samba 3.6 os usuários tentam abrir arquivos do Word, mas acontece uma
demora longa e o Word avisa que não foi possível localizar o arquivo.
O mesmo ocorre quando tentamos copiar arquivos pela rede, o Windows fica
tentando copiar até dar erro e não conclui. Tais arquivos são todos
pequenos, documentos de texto ou no máximo fotos de 2Mb.

Isto não acontece constantemente, mas tem aumentado o número de vezes, e
por ser um problema intermitente que acontece com arquivos esporádicos e
não é sempre com o mesmo arquivo, não consigo identificar o motivo.

Se eu dou um restart no samba, tudo volta ao normal por algum tempo, mas
logo começa acontecer novamente.

E notei também que as vezes quando paro o samba, ainda sobra alguns
processos rodando que não foram encerrados, e estes só param com kill -9.
Em alguns casos tais processos batem 100% de cpu.

A configuração do Samba (tanto 3 quanto 4) está na mais básica possível,
não usamos PDC nem AD, o Samba roda como standalone, coloquei e removi
configurações que dizem ser para desempenho mas nenhuma delas sanou o
problema.

O problema no Samba 4.4 é uma pasta compartilhada onde fica os executáveis
do sistema ERP da empresa, sendo que os usuários acessam através do caminho
de rede no atalho \\server\erp\compras\compras.exe por exemplo.
Quando o atalho é aberto, ou mesmo quando é executado dentro da pasta
compartilhada, acontece erro de violação de acesso.
Testei as permissões da pasta, coloquei 777 para diretório, e 444 para
arquivos, sem sucesso.

Mas no Samba 3.6 essa mesma pasta funciona sem problema algum.

OBS:
Tenho dois servidores trabalhando, estes mesmos problemas aconteceram nos
dois, FreeBSD 10.1 e no 10.3.
Tentei instalar o Samba via ports ou pkg.
Outra observação: a linha de erro no log (*unable to change to %N.core
e **refusing
to dump core) *quando eu procuro no google, os resultados aparece diversos
sites sobre FreeBSD. Será que este problema especificamente com o FreeBSD?

Segue o .conf do Samba 4.4: *http://pastebin.com/raw/R0DeELXc
*

Os erros que aparece no log do Samba 4.4 são estes:
Completo: *http://pastebin.com/raw/Xsyb9Prh
*

*Jun  7 09:03:03 samba smbd[1042]: [2016/06/07 09:03:03.285212,  0]
../source3/smbd/oplock.c:193(update_num_read_oplocks)*
*Jun  7 09:03:03 samba smbd[1042]:   PANIC: assert failed at
../source3/smbd/oplock.c(193): d->num_share_modes == 1*
*Jun  7 09:03:03 samba smbd[1042]: [2016/06/07 09:03:03.285279,  0]
../source3/lib/util.c:791(smb_panic_s3)*
*Jun  7 09:03:03 samba smbd[1042]:   PANIC (pid 1042): assert failed:
d->num_share_modes == 1*
*Jun  7 09:03:03 samba smbd[1042]: [2016/06/07 09:03:03.286172,  0]
../source3/lib/util.c:902(log_stack_trace)*
*Jun  7 09:03:03 samba smbd[1042]:   BACKTRACE: 28 stack frames:*
*Jun  7 09:03:03 samba smbd[1042]:#0 0x8040b71b1 
at /usr/local/lib/samba4/libsmbconf.so.0*

*(resumido)*


*Jun  7 09:03:03 samba smbd[1043]: [2016/06/07 09:03:03.419524,  0]
../source3/lib/dumpcore.c:313(dump_core)*
*Jun  7 09:03:03 samba smbd[1043]:   unable to change to %N.core*
*Jun  7 09:03:03 samba smbd[1043]:   refusing to dump core*


Gostaria de uma sugestão, caso ter alguém na lista que já enfrentou
problema parecido.

Att

Enio
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd